No way to prevent permanent deletion / emptying the trash bin (make files.permanent_deletion configurable)

[nomoreqwerty]

As an administrator, I want to control whether users are allowed to permanently delete items (the "Empty trash bin" action and the permanent "Delete" in the trash), so that regular users can only delete into the trash bin and data can only be purged by an administrator / by the retention policy.

User Value

• Protection against irreversible data loss by end users (accidental or malicious "Empty trash bin"), independent of backups.
• Compliance/retention requirements: data must remain recoverable for a defined period and only administrators may purge it.
• No effect on everyday work: users keep deleting files normally, they just cannot purge them.

Current Behaviour (against main)

1. The web UI gates both trash actions on the capability files.permanent_deletion plus a resource-level permission check:
   • packages/web-app-files/src/composables/actions/files/useFileActionsEmptyTrashBin.ts — isVisible() returns false if !capabilityStore.filesPermanentDeletion, then requires resources[0].canDeleteFromTrashBin({ user }).
   • packages/web-app-files/src/composables/actions/files/useFileActionsDelete.ts — the permanent delete-permanent action uses the same capability + canDeleteFromTrashBin().
   • packages/web-pkg/src/composables/piniaStores/capabilities.ts — permanent_deletion: true is the client-side default and filesPermanentDeletion is derived from it.
2. The server never reports this capability. There are no hits for permanent_deletion / PermanentDeletion anywhere in services/, pkg/ or vendor/. services/frontend/pkg/revaconfig/config.go builds the files capability block with undelete, versioning, private_links, … but no permanent_deletion, so the client always falls back to its true default. Therefore an administrator cannot turn permanent deletion off today.
3. Server-side enforcement is the CS3 permission PurgeRecycle, mapped to the Graph action libre.graph/driveItem/deleted/delete
   (services/graph/pkg/unifiedrole/conversion.go). Built-in role behaviour:
   • personal space: the owner always gets the full permission set including PurgeRecycle (decomposedfs/node/permissions.go, OwnerPermissions()), and the web client short-circuits on ownership (packages/web-client/src/helpers/space/functions.ts → canDeleteFromTrashBin() returns true for a personal-space owner, with a FIXME: server permissions are a mess currently referring to The permissions for Graph drives are not appropriate #10). → the owner can always empty their own trash.
   • project space: Manager has PurgeRecycle (reva NewManagerRole()); SpaceEditor / SpaceEditorWithoutVersions and SpaceViewer do not. → editors can delete and restore, but not purge. This is the only working control that exists today, and it is not configurable.
4. There is no setting for it either: services/settings/pkg/store/defaults/permissions.go has no trash/purge-related permission, and the web runtime config (web.config.json → options, OptionsConfigSchema in web-pkg) has no trash-related option.

Proposed Behaviour

• A new system permission (suggested name Drives.DeleteFromTrashBin, mirroring Drives.DeletePersonal / Drives.DeleteProject) with the usual constraint Own / All, checked where PurgeRecycle is assembled today — i.e. it must be enforced server-side (WebDAV/trash-bin purge, Graph, and CLI/service account excluded so the retention task keeps working).
• The server advertises the existing capability files.permanent_deletion (in the frontend/OCS capabilities block) reflecting that permission, so clients that already understand it (the web UI does, see above) work without changes. Defaults must preserve today's behaviour — this must be a no-op on upgrade.
• When the permission is not granted for a user:
  • "Empty trash bin" and the permanent "Delete" are hidden/disabled in the web UI (for personal spaces too — canDeleteFromTrashBin() must not short-circuit on ownership when the capability is off), with a hint such as "Permanent deletion is disabled by your administrator — items are removed automatically after N days";
  • direct attempts (WebDAV DELETE on a trash-bin item, purge request) return 403 Forbidden.
• Administrators keep the ability to purge: through the existing CLI (opencloud storage-users trash-bin purge-expired, … trash-bin list/restore-all/restore <spaceID>, opencloud trash purge-empty-dirs -p …) and/or the admin role/Space Admin role having the permission.
• Configurable per role/constraint (Own vs All) so that e.g. Manager/Space Admin may still empty the trash of the spaces they manage.
• Optional but appreciated: a switch in Admin Settings (General) or a setting entry in the settings API instead of environment-only configuration, plus documentation next to STORAGE_USERS_PURGE_TRASH_BIN_PERSONAL_DELETE_BEFORE / …_PROJECT_DELETE_BEFORE.

Related

• 🧹 Clean-Up File Versions #1419 — 🧹 Clean-Up File Versions: same family of problem — no retention/policy knobs for user-facing "delete" data.
• The permissions for Graph drives are not appropriate #10 — the permission model FIXME referenced from functions.ts.
• fix: align space action permissions with backend abilities web#2475 — "align space action permissions with backend abilities" (same gating code path, space actions).

Workaround available today

Only partial, and it does not cover personal spaces: give members the space role Can view (nothing lands in the trash at all) or Can edit (SpaceEditor cannot purge), and keep the Manager role for administrators; purge/restore is done by an admin via the storage-users trash-bin CLI. For personal spaces there is no way to prevent the owner from emptying the trash, and disabling personal spaces is not an option — the share jail lives inside the personal space root.

[micbar]

There is another way: many providers are using the decomposedS3 driver. They configure a S3 bucket Retention policy and do regular snapshots of the posix storage.

The deletion process in openCloud is already a two step process.

For spaces, you could use a sharing role „without trashbin“ to prevent trashbin purges and single file deletes.

That still leaves the personal space of a user where all actions are always allowed.

[nomoreqwerty]

Thanks for the suggestions. S3 retention and POSIX snapshots are useful additional safeguards, but they address recovery at the storage layer rather than the permission control requested here.

I want to let users delete files into the trash while preventing them from permanently deleting those items themselves. Recovery should remain available through OpenCloud for the configured period, without requiring an administrator to restore storage snapshots.

And the two-step deletion process only provides that protection if the user cannot immediately perform both steps. As you noted, personal space owners can still do so, which leaves the main gap unresolved. Restricting project space roles is a useful workaround, but it does not cover personal spaces.