Access Review Documentation
Access Review for Jira answers one question: who can reach which projects, and which grants are wide open?
Installing
Install from the Atlassian Marketplace. The app appears under Settings → Apps → Access Review. You need to be a Jira administrator to open it, because it reads site-wide permission schemes.
Nothing to configure. It reads the permission schemes already in your site.
Running your first review
- Open Settings → Apps → Access Review.
- Leave Permission to review at Browse projects, or choose another.
- Press Re-run.
Within a few seconds you get a headline like:
3 of 5 projects grant Browse projects to everyone — 40% restricted.
That sentence is the finding. Everything below it is the evidence.
Reading the result
The main table lists every project and every holder of the chosen permission. Wide-open grants are sorted to the top and marked in red.
| What you see | What it means |
|---|---|
| Anyone on the internet | The project is public. Anonymous visitors hold this permission. |
| Every logged-in user | Anyone with a Jira licence on your site, whether or not they work on this project. |
Group: name |
The named group holds it. The app reports the group's name, not its members. |
Project role: name |
The role holds it on that project. Who is in that role varies per project. |
User: name |
The permission is granted to one named individual. |
| Unknown | The scheme could not be read. Reported rather than hidden — investigate it by hand. |
"Which projects each group or role can reach" inverts the view. Start from a group and see its full reach. This is the table that answers "what would happen if someone were added to this group?" — and it routinely surprises people.
Exporting for the audit record
Press Export CSV. The panel below fills with comma-separated rows:
Project,Name,Permission,Scheme,Granted to,Holder type,Wide open
Select the text, copy it, and save it as a .csv file. Auditors generally want
the date and the person who ran it recorded alongside — the app does not add
those, so put them in the file name or the covering note.
Which permissions are worth reviewing
Browse projects is the default and the usual starting point, because it defines who can see a project at all.
After that, the ones that most often produce findings:
- Administer projects — who can change a project's own configuration
- Delete issues — a destructive permission that is often too broad
- Manage sprints — matters in regulated teams
- Transition issues — where a workflow control is meant to bite
Run the same review for each and keep the exports together.
Things worth knowing
jira-guest-member and atlassian-addons-project-access appear on
everything. Jira adds these itself. Their presence is normal; a surprising
permission held by them is not.
A grant is not the same as access. The person must also hold a Jira licence. The report describes the permission scheme, which is what an access review is about.
Team-managed projects carry an automatically generated scheme, often shown as "Simplified Permission Scheme". They are included in the report.
Large sites are slow. One API call per project is needed to resolve its scheme. Several hundred projects will take a while.
What it will not do
No permission editing, no user provisioning, no licence optimisation, no identity-provider sync, and no expansion of groups into named people. The app is read-only and asks for read-only scopes. That is the point: an access-review tool that could also change permissions would itself be part of what an auditor has to review.
Getting help
support@bobook.club — see the support page for what to include.