Grants

The grants page at /permissions/grants edits the permissions of one role. It is also reachable from the table-definition workspace, which edits a table’s grants without leaving its own page.

The matrix

For the selected role, the page shows a grant matrix grouped by profile and by the wildcard objects that cover every profile:

• data:* and data:<profile>/* — table data grants;
• journal:* — journal grants;
• ecb:* — exchange-rate read access.

The columns are the four actions read, insert, update, and delete. Structural roles may only ever be granted read, so their write columns are unavailable and the page says why.

Each cell is one of:

• direct — held by the role itself, so revoking it here works;
• inherited — already covered by the parent role or a wider object;
• allowed — whether the action may be granted on this object for this role at all.

Shortcuts

Shortcuts post a list of object|action pairs rather than a special “all” rule:

• Read everything — read on every wildcard object;
• Full access to a profile — every allowed action on that profile’s wildcard objects;
• Clear — revoke everything the role holds directly, tables included.

Because shortcuts grant the wildcard objects, they keep covering profiles and tables created later.

Applying changes

POST /permissions/grants/apply sends the role, a grant or revoke mode, and the resolved pairs. Each pair becomes one GrantPermission or RevokePermission call, and the first refusal stops the run and is reported.

Revoking tolerates a pair the role does not hold directly, which is what makes “remove all of this” idempotent. The form’s return_to field only accepts a path on this site, so it cannot be turned into an open redirect.