mirror of
https://github.com/projectsend/projectsend.git
synced 2026-09-17 09:05:08 +00:00
ignacionelson
616a355d54
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."
81 lines
3.0 KiB
PHP
81 lines
3.0 KiB
PHP
<?php
|
|
|
|
declare(strict_types=1);
|
|
|
|
namespace App\Modules\Files;
|
|
|
|
use App\Models\User;
|
|
use App\Modules\Files\Access\StaffLibraryScope;
|
|
use App\Modules\Files\Models\Folder;
|
|
|
|
/**
|
|
* Folder ownership rules, mirroring FilePolicy: own vs others' via the
|
|
* v1 permission pairs. Which staff see which folders is the
|
|
* StaffLibraryScope's job — and for client-scoped staff the policy AND's
|
|
* that scope into every action so direct access stays inside the boundary.
|
|
*
|
|
* Clients may create/rename/delete only folders they created themselves
|
|
* (create_own_folders doubles as the single toggle for the whole client
|
|
* folder-management feature, since clients have no edit_files/delete_files
|
|
* equivalent) — see MyFoldersController.
|
|
*/
|
|
class FolderPolicy
|
|
{
|
|
public function __construct(
|
|
private readonly StaffLibraryScope $scope,
|
|
) {}
|
|
|
|
public function view(User $user, Folder $folder): bool
|
|
{
|
|
if ($user->isStaff()) {
|
|
return ($user->can('upload') || $user->can('edit_files') || $user->can('edit_others_files'))
|
|
&& $this->scope->allowsFolder($user, $folder);
|
|
}
|
|
|
|
return Folder::query()->whereKey($folder->id)->visibleToClient($user)->exists();
|
|
}
|
|
|
|
public function update(User $user, Folder $folder): bool
|
|
{
|
|
if (! $user->isStaff()) {
|
|
// A client owns their home folder -- created_by is them, which
|
|
// is how they can see it at all -- so ownership alone would let
|
|
// them rename it. It is structure rather than something of
|
|
// theirs to arrange: its name follows the account, and the
|
|
// administrator reading /files relies on that. Renaming it is
|
|
// refused rather than allowed and then silently overwritten the
|
|
// next time the account is edited.
|
|
if ($folder->isHome()) {
|
|
return false;
|
|
}
|
|
|
|
return $folder->isOwnedBy($user) && $user->can('create_own_folders');
|
|
}
|
|
|
|
$permitted = $folder->isOwnedBy($user) ? $user->can('edit_files') : $user->can('edit_others_files');
|
|
|
|
return $permitted && $this->scope->allowsFolder($user, $folder);
|
|
}
|
|
|
|
public function delete(User $user, Folder $folder): bool
|
|
{
|
|
// Nobody deletes a home folder from a folder screen, staff
|
|
// included. Deleting one cascades over everything the client has,
|
|
// and it would leave their portal pointing at a folder that is not
|
|
// there -- an account still gets erased through the erasure flow,
|
|
// which is where destroying somebody's content is the declared
|
|
// intent rather than a side effect of tidying a tree.
|
|
if ($folder->isHome()) {
|
|
return false;
|
|
}
|
|
|
|
if (! $user->isStaff()) {
|
|
return $folder->isOwnedBy($user) && $user->can('create_own_folders');
|
|
}
|
|
|
|
$permitted = $folder->isOwnedBy($user) ? $user->can('delete_files') : $user->can('delete_others_files');
|
|
|
|
return $permitted && $this->scope->allowsFolder($user, $folder);
|
|
}
|
|
}
|