User Management, Groups, Roles, and Permission Schemes
Identity and access layers
Access in Jira flows through layers: users belong to groups; groups receive global permissions and can be referenced in project roles; project roles receive project permissions via the permission scheme. Candidates must be able to explain why a user can or cannot perform an action by walking these layers. Permission schemes grant or deny specific permissions (Browse Projects, Create Issues, Transition Issues, Administer Projects) to grantees such as application access, groups, roles, or the reporter/assignee.
Issue security schemes are a separate, finer layer that restricts who can see individual issues within a project. Do not confuse them with permission schemes. Application access determines whether a user can use Jira at all, independent of project permissions.
Traps to watch
- Granting a permission to a group when the intent was project-specific; roles are the better tool.
- Assuming a user in a role automatically has global access; global permissions are separate.
- Forgetting that removing a user from a group affects every project referencing that group.
- Confusing issue-level security with project-level permission.
Rule of thumb
Diagnose access problems from the outside in: application access → global permission → project permission (via role/group) → issue security. The first layer that fails is the answer.
Worked example: a contractor can browse a project but sees only some issues. Project permission is fine; the issue security scheme is filtering the rest. Adjust security levels, not the permission scheme.