Access and roles
The permission model at a glance
Section titled “The permission model at a glance”Docuflair Redact & Mask uses a thoroughly role-based permission model:
- A role bundles eight individual permissions — read, create, change, upload, delete, move, manage permissions, approve — plus a download level (Full (original) / PDF only / Redacted only / No download).
- A grant assigns a role to a principal (a user or a group) at a level: the whole project, an individual folder, a tag — or the tenant (a special case, see below).
- The model is fail-closed: without a matching grant a user has no access at all — they do not even see the project. Superadmins bypass the permission system entirely.
Four standard roles are provided (adjustable, but not deletable):
| Role | Description |
|---|---|
| Reader | Read only; downloads redacted only. |
| Editor | Read, upload, change, move; downloads as PDF. |
| Manager | Full project access including delete and permission management. |
| External reviewer | Read and approve only; downloads redacted only, no upload. |
Managing roles
Section titled “Managing roles”On the Roles page (/admin/roles) you maintain the role catalogue:
“New role” opens the dialog with a name, a description, the eight permission checkboxes and the download level. Standard roles carry the “Standard” badge — their name is fixed, while permissions and description can be changed. A role that is still assigned cannot be deleted.
Example — the role “Scanning service provider”: tick only upload and read, with the download level No download — the external provider can deliver documents and see the list, but download nothing.
Granting access (the grant matrix)
Section titled “Granting access (the grant matrix)”The Access page (/admin/permissions) is the central place for assigning permissions. Select the project at the top, then the level in the “Manage” tab:
- Whole project — the normal case: the table shows every user and group; in each row you choose the role (or “No access” to remove the assignment). Changes save immediately.
- Folder — after selecting a folder you assign different roles for subsections; the “Inherit” column controls whether the grant is passed on to subfolders. A direct folder grant overrides the inherited project grant.
- Tag — roles for documents carrying a particular tag. Where tag grants exist in a project, they act as an additional gate for documents marked that way.
- Tenant (create projects) — a special case, selectable only by superadmins: a grant at tenant level with the create permission allows the principal to create new projects (whoever creates one automatically becomes its manager). Such grants do not propagate into existing projects.
Below the matrix, a footnote recalls the basic principle: “No access without a matching grant (fail-closed). Superadmins always have full access.”
Checking effective permissions
Section titled “Checking effective permissions”The “Effective permissions” tab answers the question “what can this user actually do?”: select a user, and the table shows the resulting permissions per folder (ticks) and their source (“Direct”, “Project”, “Inherited from …”, “Superadmin”), with the Download and Upload badges above it.
Example — resolving an access problem: a user reports “I cannot see the project.” → the Effective permissions tab, select the user: if there is not a single tick there, the grant is simply missing — assign the Reader role (or a more suitable one) in the Manage tab.