Conditional Trash Bin Restore Permission for Space Editors

[dj4oC]

Title:
As a space editor, I want to restore files from the trash bin only if I have a specific IDM role, so that file recovery permissions can be tightly controlled. Space managers should always be able to restore files.

Description:
In oCIS, space editors typically have permissions to manage files and folders within a space. However, restoring deleted files from the trash bin can be a sensitive operation. To enhance access control, we want to allow space editors to perform trash bin restore operations only if they possess a specific IDM role (e.g., SpaceTrashRestore).
Space managers, on the other hand, should always be allowed to restore deleted files, regardless of their IDM role.

Acceptance Criteria:
Default Behavior:
• Space editors without the specified IDM role cannot restore items from the trash bin.
• Space managers can always restore items, regardless of IDM role.
Permission Check:
• When a user attempts a restore, the system first checks if they are a space manager. If yes, the operation is permitted.
• If the user is a space editor, the system checks for the presence of the defined IDM role (e.g., SpaceTrashRestore).
With Role:
• If the space editor has the SpaceTrashRestore role, they are allowed to restore deleted files and folders.
Without Role:
• If the space editor lacks the role, the restore operation is denied, and an appropriate message is shown (e.g., “You are not authorized to restore files”).
Audit Logging:
• Any denied restore attempts due to missing roles are logged for audit and traceability.
Configurable Role Name:
• The required IDM role can be configured via environment variable or config file (e.g., OCIS_TRASHBIN_RESTORE_ROLES=SpaceTrashRestore) (plural).
UI Behavior:
• The “Restore” button or action is disabled or hidden in the UI if the space editor lacks the required role.
• The restore option is always available to space managers.

Notes:
• Applies consistently across Web UI, WebDAV, and API endpoints.
• Supports security and compliance use cases requiring tighter controls on file recovery actions.

[dj4oC]

@kobergj would you mind to check the possibilities? 😍

[kobergj]

I really don't like the idea of mixing ocis permissions and some claim permissions. We should have only ONE source of truth when it comes to permissions. Maybe we could use some sort of middleware to dynamically change user permissions. OR we make the ocis permissions source configurable. That way we could give the IDM full control on who accesses what. But I don't like the idea because it will lead to misconfigurations with massive impact on security.

Anyways this will require a new role in ocis EditorRestore or EditorNoRestore.

This requires some product decisions.

[dj4oC]

Good point. Thank you for your pov