User Access Review for Jira — Documentation

Last updated: 14 August 2026. Applies to the User Access Review for Jira Cloud app.

User Access Review answers two questions about a Jira project on one page: who has access, and in what role, and what changed recently, and by whom. It is read-only and changes nothing in Jira.

Requirements

• Jira Cloud. The app adds a page inside a project, so you need at least one project.
• The Audit Log tab reads Jira's own auditing REST API. That endpoint is restricted by Atlassian; if your site or plan does not return records for it, the tab shows an error message instead of a table. The Permissions tab works independently of this.
• Nothing else — no account, no API key, no external service.

Installation

1. Install the app from the Atlassian Marketplace, or from within Jira via Settings → Apps → Manage apps and searching for it there.
2. Approve the requested Jira scopes when prompted (see the privacy statement for what each one is for).
3. Open any project — the page is available immediately, with no configuration step.

Where to find it

The app registers a project page. Open a Jira project and look for Permissions & Audit in the project sidebar — the in-product module still carries the previous name; it follows on the next app release. Everything happens on that one page, split into two tabs.

Using User Access Review

Permissions tab

1. Opening the tab loads every project role of the current project and the users and groups assigned to each of them. One row is shown per user-or-group and role combination.
2. Each row gets a derived access level lozenge: Admin, Write, Read or App. Group rows carry a group tag next to the name.
3. Use the two dropdowns to filter by a specific user or a specific role. The counter next to them shows how many entries, unique users and unique roles are currently visible.
4. Column headers sort the table; long lists are paginated at 25 rows per page.

Audit Log tab

1. Pick a period: last 7, 30 or 90 days (30 is the default). Changing it reloads the table.
2. The table lists date, the user Jira reports as the author, the action summary, and a detail column that flattens the changed values into field: from → to form.
3. Export CSV opens a dialog containing the full table as CSV text, with a suggested filename such as audit-log-PROJ-2026-07-29.csv. Copy the block and paste it into a file; it is written with a byte-order mark and CRLF line endings so Excel opens it cleanly.

There is no background job and no scheduled trigger: data is fetched fresh from Jira on each load.

Limitations

• The access level is derived from the role's name (a name containing "admin" maps to Admin, "viewer" or "read" to Read, "addon" to App, anything else to Write). Unusual custom role names may therefore map imprecisely.
• The Permissions tab covers project roles only. Permission schemes, issue-security levels and global permissions are not shown, and group members are not expanded — a group appears as a single row.
• If one or more roles cannot be read, the table still renders and a warning banner reports how many roles were skipped.
• Jira's auditing API has no project parameter. The app passes the project key as a free-text filter, so results can be incomplete or occasionally include loosely related records. A query returns at most 1000 records.
• The audit User column shows whatever Jira returns for the record's author; where Jira gives no full name, this is an Atlassian account ID rather than a display name.
• The CSV export is not a true file download. Forge UI Kit apps have no DOM access, so the app shows the CSV in a copyable code block instead.
• Both tables are generated as the app, not as you, so the page can show the full picture rather than a partial one. Access is therefore checked in the app before anything is read: both the permissions table and the access-changes view require Administer Projects on that project. Users without it get an explicit refusal. The app does not ask for any site-wide administrator permission.
• Access changes come from the app's own dated snapshots, not from Jira's audit log. One snapshot is taken per project per day, so history starts on the day you install — a period from before that cannot be reconstructed. Snapshots are kept for 400 days, just over a twelve-month audit period.

Support

Questions, bugs or feature requests: info@kyc-checks.nl.