Access and Permissions
Access and Permissions
Access in Risk Management for Jira is deliberately small. There is one table that decides who can open what, and it has three fields.
GRANT = (who, where, what role)
Who is one or more people or groups. Where is an organisation unit, a workspace, or a single register. What role is one of the roles you have defined. That is the entire model.
If somebody can open a record, exactly one row explains why. There are no permission schemes, no override lists, and no per-register access tab quietly contradicting the one above it.
In this section
| Page | What it covers |
|---|---|
| Organisation structure | The single tree that accountability, reporting and access all resolve against. |
| Groups | Nestable groups, group purposes, and rule-based membership. |
| Roles and permissions | Built-in roles, the reach ladder, and building a custom role. |
| Granting access | Writing a grant, and how far it reaches. |
| Field and step access | Restricting individual fields and workflow steps. |
The four rules
- One table. No ACLs, no permission schemes, no override lists.
- Highest wins, never intersect. Roles are never merged or intersected. Equal-rank collisions are flagged, not guessed.
- Ownership is additive. Being the owner, creator or assignee adds capability. It never takes any away.
- Independence is a ceiling, not a floor. Members of an independence group are capped at read-only everywhere except inside the sealed workspace their own function owns.