How-to
Jira permission scheme audit: what to check
Go through every permission scheme your projects use and ask who gets each permission. Four problems cause most of the trouble: projects open to the public, edit or delete rights for every logged-in user, single people named in schemes, and deactivated accounts left in project roles.
The audit by hand
- List the schemes. In Jira settings, open the permission schemes page. Write down each scheme and the projects using it. Schemes no project uses can wait. With dozens of schemes,
/rest/api/3/permissionscheme?expand=permissionsreturns them all with their grants in one call. - Public access. Check who has Browse Projects (
BROWSE_PROJECTSin the API). If it goes to the public, anyone can read those projects without logging in. You might want that for a public help project. Usually it's a leftover. - Wide grants. Look at the edit, move and delete work item permissions and Administer Projects (
EDIT_ISSUES,MOVE_ISSUES,DELETE_ISSUES,ADMINISTER_PROJECTS). If they go to every logged-in user, anyone with a Jira seat can change or delete work there. - Named people. Grants to one user at a time are hard to review and outlast job changes. Move them to a group or a project role.
- Project roles. Open each project's role assignments and remove deactivated accounts. They can't log in. The entries come back to life if the account is reactivated, though.
- Keep notes. Write down what you changed and the date. Next quarter you'll only check what's new.
Faster with the Findings tab
Access & License Audit reads every scheme your projects use. It lists these problems with a severity and the projects affected: public access, sensitive permissions for every logged-in user, people named directly, deactivated accounts in roles, and unused groups. Nothing gets changed. You decide what to fix.
