Implement WebDAV server as import source with Filament integration and user folder structure

[N3XT0R]

Summary

We want to introduce a proper WebDAV server implementation as the new import source for incoming files.

This is intended to replace the current ingest:scan entry mechanism, which currently mixes multiple responsibilities and is still based on scanning a dynamic filesystem path.

The new approach should provide:

• a WebDAV server endpoint
• a user-oriented folder structure
• personal temporary spaces for uploads
• administrative integration into Filament

Uploads are restricted to ZIP archives, which will be extracted locally on the server before further processing.

This issue is intentionally limited to the WebDAV layer and its integration.
The existing event-based ingest pipeline already exists in the new major version and will be integrated separately.

---

Background

The current ingest:scan command still relies on scanning a dynamic path recursively and acts as the source entrypoint for imports.

That approach is no longer ideal because it mixes concerns:

• source discovery
• filesystem traversal
• import triggering

What we want instead is a dedicated, explicit import source based on WebDAV.

WebDAV should become the managed upload/import surface, while the downstream ingest pipeline remains a separate concern.

---

Goals

• implement a WebDAV server in the Laravel application
• use WebDAV as the new source for incoming imports
• replace the old dynamic-path-based ingest:scan entry model
• define a clear user-based folder structure
• provide each user with a personal temporary upload/import space
• restrict uploads to ZIP archives
• integrate WebDAV management and visibility into Filament

---

Non-goals

This issue is not about:

• redesigning the ingest pipeline
• implementing the downstream event-based processing
• changing deduplication logic
• implementing final storage distribution logic
• replacing unrelated parts of the domain model

Those concerns are handled elsewhere.

---

Scope

This issue covers four main parts:

1. WebDAV server implementation

A proper WebDAV server should be added to the application as the new managed import entrypoint.

Expected capabilities:

• authenticated access
• upload support
• browsing of allowed directories
• controlled user-scoped file access
• Laravel-compatible integration

2. User-based temporary folder structure

Each user should have an assigned personal temporary space that acts as their upload/import source.

Structure:

/webdav/
  {user-id}/

Core requirements:

• each user gets a clearly assigned temporary import area
• the structure is deterministic
• the source context is explicit
• the space is temporary and acts only as the ingest source before files are moved into cloud storage

3. Upload constraints and processing expectations

• only ZIP archives are considered valid input for ingest
• ZIP files are extracted locally on the server before entering the ingest pipeline
• non-ZIP uploads are not valid input
• non-ZIP uploads should be removed automatically by a dedicated command
• a dedicated command will replace the old ingest:scan scanning logic for the WebDAV-based import source

4. Filament integration

The WebDAV feature should be visible and manageable from Filament.

Expected capabilities:

• display connection instructions for the user
• allow users to create WebDAV credentials
• allow users to regenerate WebDAV credentials when needed
• show the assigned WebDAV path / user space
• provide administrative visibility into the WebDAV assignment model

---

Data model

WebDAV access should be modeled separately from the main user entity.

A dedicated table should be introduced, e.g.:

user_webdav_accounts

Example structure:

• id
• user_id
• username
• password_encrypted
• enabled
• max_archive_size (nullable)
• max_file_count (nullable)
• last_used_at
• created_at
• updated_at

Key decisions:

• WebDAV credentials are not stored directly on the users table
• credentials are treated as a separate technical access layer
• credentials must be encrypted at rest
• each user has at most one WebDAV account (initially)
• the system should remain flexible for future extensions (e.g., rotation, multiple credentials)
• limits for archive size and file count are not enforced initially, but the schema must support them for future use

The WebDAV folder path itself can be derived deterministically:

/webdav/{user-id}/

---

Why this change is needed

The current ingest:scan command is not just a source definition; it also embeds operational logic around how imports are discovered.

That is not the right abstraction anymore.

WebDAV gives us:

• an explicit import surface
• a cleaner separation of concerns
• a user-scoped upload model

Additionally, restricting uploads to ZIP archives provides:

• a predictable input format
• controlled extraction on the server
• better consistency for downstream processing

Instead of “scan some arbitrary path”, the source becomes:

“ZIP archives uploaded into a managed personal WebDAV space”

That is the intended model.

---

Proposed implementation direction

WebDAV server

Use a dedicated WebDAV server implementation for Laravel, most likely based on SabreDAV.

Authentication

WebDAV authentication should be handled separately from the default application authentication.

Requirements:

• WebDAV credentials are stored in the database
• credentials are encrypted at rest
• authentication is validated against these stored WebDAV credentials
• this will likely require a dedicated authentication guard for WebDAV

Folder assignment model

Map each user to a deterministic temporary upload/import directory.

ZIP handling

Ensure that:

• only ZIP archives are treated as valid ingest input
• ZIP archives are extracted locally on the server
• non-ZIP uploads are cleaned up automatically by command
• extracted files are handed over to the ingest pipeline

Filament admin integration

Expose configuration and visibility for this WebDAV setup in the admin UI, including credential creation/regeneration and user-facing connection details.

---

Open design questions

• Do we need limits on archive size or number of files?
• Should Filament only show configuration state, or also a live file overview?
• Should users only see their own WebDAV space, or are shared/admin spaces also needed?

---

---

Filament integration

The WebDAV feature should be visible and manageable from Filament.

Expected capabilities:

• display the WebDAV endpoint URL for the user
• show a table of the user's WebDAV credentials (username, creation date, etc.)
• do not expose the password (it is user-defined and stored encrypted)
• allow users to create WebDAV credentials
• allow users to regenerate WebDAV credentials when needed
• show the assigned WebDAV path / user space

---

Access model

• users can only access their own WebDAV space
• no shared or admin-level WebDAV spaces are required in the initial implementation
• the structure is strictly user-scoped

---

Acceptance criteria

• a WebDAV server endpoint exists in the application
• authenticated users can access only their own WebDAV space using dedicated WebDAV credentials
• WebDAV credentials are stored encrypted in the database
• a dedicated WebDAV authentication mechanism is implemented, likely via a separate guard
• a dedicated user_webdav_accounts (or equivalent) table exists
• the table supports optional limits (max_archive_size, max_file_count) but does not enforce them initially
• each user has a deterministic personal temporary upload/import folder
• only ZIP files are treated as valid input
• non-ZIP uploads are automatically removed by command
• ZIP files are extracted locally before entering the ingest pipeline
• a dedicated command replaces the old ingest:scan scanning logic for the WebDAV-based import source
• Filament allows users to:
  • view the WebDAV URL
  • see their credentials (without password)
  • create credentials
  • regenerate credentials
• the implementation is ready to be connected to the existing event-based ingest pipeline

---

Notes

This issue only establishes the WebDAV import surface, the user folder model, and the ZIP-based input contract.

The downstream processing pipeline already exists separately and is not the focus here.