📐 Diagram of the real flow, from the code in this repo

How the portal works

The path of one project — from the client's initial document upload to an authorization-checked download of the finished files — exactly as implemented in the controllers.

Client Staff / system

Submits a project with files

Up to 20 files at once (PDF, DOC/DOCX, XLS/XLSX, PNG/JPG, ZIP), 25 MB max each. The project starts with status "submitted".

ProjectController@store

Files are stored on a private disk

Each file gets a randomly generated UUID name and lives outside any publicly reachable folder — there is no URL that just opens the file.

ProjectFileUploadService::storeOne()

Staff review and move the status

A staff dashboard lists every project, filterable by status.

submitted in progress needs info completed

Admin\ProjectController@updateStatus

If needed — client adds more files

If the status is "needs info", the client uploads additional documents and the project automatically moves back to "submitted".

ProjectController@storeFiles

Staff upload the finished files

Final deliverables are tagged separately as "deliverables" — distinct from the client's original input files.

Admin\ProjectController@storeDeliverables

Client downloads the deliverables

Every download goes through a check — does the requester own this project (or are they staff) — before the file is even read from disk.

ProjectFileController@download

    Technical details
    Files are never served directly — every download goes through a controller that checks authorization before reading the file from disk.
A client only ever sees their own projects (Project::scopeForClient) — requesting someone else's project returns 403, not 404, so it's clearly a permissions block, not a missing resource.
Every file's type and size are validated on upload — only known document formats are allowed, capped at 25 MB per file.

  