mirror of
https://github.com/projectsend/projectsend.git
synced 2026-09-17 09:05:08 +00:00
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."
122 lines
4.8 KiB
PHP
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.'));
|
|
}
|
|
}
|