Permission Schemes, Project Roles, and Issue-Level Security
Two different questions
Permission schemes answer "what may this user do in this project?" - Browse Projects, Create Issues, Edit Issues, Transition Issues, Assign Issues, Administer Projects, Set Issue Security, Delete Issues. Each permission is granted to a user, group, project role, "Any logged-in user", or application access. Issue-level security answers "which issues within this project may this user see?" - a security level assigned to the issue restricts it to the users, groups and roles listed on that level of the project's issue security scheme.
They combine
To read a secured issue a user needs Browse Projects and membership of the issue's security level. If an issue has no security level, everyone with Browse Projects sees it. Only holders of the Set Issue Security permission can assign a level, and a project administrator is not automatically inside a security level.
Traps
- "Administer Projects" is per project and does not allow scheme editing; only the Administer Jira global permission does.
- Granting to a group applies in every project that uses the scheme - often wider than intended.
- Issue security is invisible in the issue list; a user simply sees fewer issues, which reads as a bug.
- Permissions granted to "Any logged-in user" can include people with no Jira product access, depending on the grantee chosen.
- Duplicated schemes drift; audit which projects use which scheme before editing.
Rule of thumb: the permission scheme decides whether a user can act; issue-level security decides which issues they can act on. When access looks wrong, run the Permission Helper before blaming the workflow.