Permissions

What it is#

Permissions is a grid: every permission key down the side, the four roles across the top, and a tick where the role holds the key. A second tab does the same for one person, so somebody can be given a key their role does not carry — or have one taken away that it does.

A key is named <resource>.<verb>. Anything ending .view is read-only; every other verb changes something and writes an audit row when it is used.

How to get there#

Admin → People → Permissions. The console needs the ADMIN role, and reading or writing the matrix is keyed on role.manage.

How to use it#

Change what a role may do#

1. Stay on the By role tab.
2. The grid is grouped by category — Project, Task, Time, Billing, Security and so on. Click a category header to collapse it.
3. Each row shows the human description and the raw key underneath, e.g. project.delete.
4. Click a cell to toggle it. The change saves as you click; there is no save button.
5. A cell with an amber dot differs from the platform default. Hovering says which: "Platform default" or "Customised for this workspace".
6. The count at the top right of the tabs — *"12 customised for this workspace"* — is the total across all four roles.

Give one person more (or less) than their role#

1. Switch to the By member tab.
2. Pick somebody from the list on the left.
3. The header says what they inherit — *"Inherits 84 from MEMBER · 2 overrides"*.
4. Toggle any key. A cell that no longer matches the role is labelled in amber beside the key: "granted · role says no", or "revoked · role says yes".
5. Reset to role clears every override for that person and returns them to exactly what their role grants.

What it affects#

• Every holder of the role, immediately. Saving publishes the change to the workspace, and open tabs re-read their own keys rather than waiting for a reload.
• The navigation rail. Most sidebar rows are drawn from a .view key, so a toggle here adds or removes a destination from somebody's navigation.
• Only this workspace. A change is stored as a delta row against this company. The platform-wide default table is shared by every tenant and is never written from here. If you set a cell back to whatever the platform default says, the delta row is deleted rather than stored, so the matrix stops showing it as customised.
• The audit log records every grant, revoke and reset with the key, the target and the actor.

On mobile#

This screen is web only. A permission matrix is not a 390pt document.

Limits and gotchas#

• A grant does not take effect until the RBAC seed has run. The permission key catalogue and the default role grants live in a global table that is reconciled by a seeding step, not by this screen. A permission key that has been added to the product but not yet seeded resolves to nothing, and the toggle you flip for it is inert. Per-member overrides are never touched by that reconciliation — those are your deliberate edits.
• **Admin cannot give up role.manage.** That cell is disabled with the tooltip *"Admins always keep this — removing it would lock everyone out of this page"*, and the server refuses it as well. There would be no way back short of a database edit.
• Admin holds a wildcard. Its row shows every key ticked because the role grants *, so a key added to the product tomorrow reaches admins without any action here.
• **Some .view keys are off the everyday floor without being secret.** client.view, contract.view, report.view, proof.view, kb.view, form.view and playbook.view are grants rather than inheritances — a developer hired to close tickets has no errand on the client book. Turn any of them on for a role here and the row appears in that person's nav on their next request.
• A key that reads as a permission but is not in the catalogue does nothing. If a gate is written against a key that does not exist here, it refuses everybody, admins included.
• The grid is optimistic: a cell flips as you click and reverts with an error toast if the write is refused.

Related#

• Roles — the four roles, headcounts and reset-to-default.
• Members — who holds which role.
• The permission model — how a key is resolved on a request.
• Roles and permissions — the concepts.