Files
ignacionelson 616a355d54 Give each client a folder of their own, standing in for the root
A client who may create folders creates them at the top of the library,
beside the ones staff made, and their uploads land at the root too. An
administrator opening /files gets one flat pile with nothing saying which
parts belong to whom.

With the new "Give each client a folder of their own" setting, every new
client gets a folder named after them and it acts as their root: what they
upload and any folder they create goes inside it. /files becomes a list of
clients rather than a pile.

The sentence this feature has to keep true: **the home is a default
location, not a boundary.** Folder::scopeVisibleToClient is untouched, so a
folder staff shared with a client still reaches them and sits beside their
own. Making the home a jail would have silently revoked every share that
already exists -- a data-access change wearing the clothes of a tidying-up
feature. There is a test named after that rule.

What the client sees is the *inside* of their folder, not a folder wearing
their own name, which is not information to them. The breadcrumb is trimmed
of it for the same reason: "Invoices", not "Acme Ltd / Invoices".

Some decisions worth naming:

- **A column, not a convention.** `folders.home_for_user_id`, unique.
  Matching on the name breaks the moment two clients share one, and
  `created_by` plus a null parent catches every root folder a client ever
  made themselves. The question is asked on each upload and each portal
  listing and the answer has to be exact.
- **created_by is the client**, because that is how scopeVisibleToClient
  already grants somebody their own folder -- no assignment row to keep in
  step with it. That is also why this writes the row rather than calling
  FolderService::create(), which takes created_by from auth()->id().
- **On model events**, not in the services that make and rename clients.
  There are nine of those (ClientAccounts, ClientProvisioning, the profile
  screen, two update endpoints, AccountConversion, invitations, LDAP,
  social) and a rule repeated in nine places is missing from the tenth.
- **Turning the setting on creates nothing.** Existing clients get a folder
  when an administrator presses a button that says how many are waiting,
  and it reports created/total/already-had afterwards. Somebody should be
  able to switch this on, look, and switch it off without having
  reorganised a library. It moves no files either.
- **Nobody deletes a home from a folder screen**, staff included, and the
  client cannot rename theirs -- they own it, so ownership alone would have
  let them, and its name follows the account anyway.
- **The name always follows the client**, over a hand-typed one. A folder
  still called "Acme Ltd" under an account now called something else
  misleads the administrator the feature exists for.

Verified in a real browser as well as in tests: the screen mounts, the
panel reads "24 of your existing clients have no folder yet", and pressing
the button answers "24 of 24 clients got a folder. 0 already had one."
2026-09-17 00:22:29 -03:00

122 lines
4.8 KiB
PHP

<?php
declare(strict_types=1);
namespace App\Modules\Files\Http\Controllers;
use App\Http\Controllers\Controller;
use App\Modules\Audit\Action;
use App\Modules\Audit\ActivityLogger;
use App\Modules\Files\Folders\ClientHomeFolders;
use App\Modules\Files\Folders\FolderService;
use App\Modules\Files\Models\File;
use App\Modules\Files\Models\Folder;
use App\Support\Rules;
use Illuminate\Http\RedirectResponse;
use Illuminate\Http\Request;
use Illuminate\Support\Facades\Gate;
/**
* Client-facing folder creation/rename/delete — the client portal's
* counterpart to FoldersController, gated by create_own_folders (see that
* permission's docblock) rather than staff middleware. A client may only
* ever nest a new folder inside one already visible to them
* (Folder::scopeVisibleToClient), so a created folder is automatically
* visible to them and to any staff with access to their content — see
* StaffLibraryScope::folders(), which already ORs in visibleToClient()
* per assigned client.
*/
class MyFoldersController extends Controller
{
public function __construct(
private readonly FolderService $folders,
private readonly ActivityLogger $activity,
private readonly ClientHomeFolders $homeFolders,
) {}
public function store(Request $request): RedirectResponse
{
$client = $request->user();
abort_unless($client !== null && $client->isClient(), 404);
// Creating one requires upload too — an empty folder a client can
// never put anything in isn't useful on its own (renaming/deleting
// an existing one, below, doesn't carry this requirement: it stays
// theirs to manage even if upload is later revoked).
abort_unless($client->can('create_own_folders') && $client->can('upload'), 403);
$validated = $request->validate([
'name' => ['required', 'string', 'max:255'],
'parent_id' => Rules::folderId(),
]);
$parent = null;
if (($validated['parent_id'] ?? null) !== null) {
$parent = Folder::query()->visibleToClient($client)->whereKey($validated['parent_id'])->firstOrFail();
}
// No parent named means the top of what this client sees -- which,
// where the installation gives them a home, is inside it rather
// than at the root of the library. Without this a client creating a
// folder would put it beside the staff folders, which is precisely
// the mess the home folder exists to end.
$parent ??= $this->homeFolders->for($client);
$folder = $this->folders->create($validated['name'], $parent);
$this->activity->log(Action::FolderCreated, subject: $folder);
return back()->with('success', __('Folder created.'));
}
public function update(Request $request, Folder $folder): RedirectResponse
{
Gate::authorize('update', $folder);
$validated = $request->validate(['name' => ['required', 'string', 'max:255']]);
$folder->update(['name' => $validated['name']]);
$this->activity->log(Action::FolderRenamed, subject: $folder);
return back()->with('success', __('Folder renamed.'));
}
public function destroy(Folder $folder): RedirectResponse
{
Gate::authorize('delete', $folder);
$client = auth()->user();
assert($client !== null);
// Deleting a folder cascades to every file in its subtree, and a
// File's `deleted` hook removes the bytes from disk — there is no
// restore. Owning the folder is not authority over content someone
// else put in it: staff routinely upload into a client's own folder,
// and the client can see those files without being able to delete
// them individually (FilePolicy::delete denies clients outright).
// Refuse rather than silently destroy them.
$foreignFiles = File::query()
->whereIn('folder_id', $folder->subtreeFolderIds())
->where(fn ($query) => $query->whereNull('uploaded_by')->orWhere('uploaded_by', '!=', $client->id))
->count();
if ($foreignFiles > 0) {
return back()->with('error', trans_choice(
'This folder cannot be deleted: it holds :count file you did not upload.|This folder cannot be deleted: it holds :count files you did not upload.',
$foreignFiles,
['count' => (string) $foreignFiles],
));
}
$name = $folder->name;
$parentId = $folder->parent_id;
$this->folders->delete($folder);
$this->activity->log(Action::FolderDeleted, context: ['name' => $name]);
return redirect()->route('my-files.index', $parentId !== null ? ['folder' => $parentId] : [])
->with('success', __('Folder deleted.'));
}
}