1. Introduction
Permission Auditor for Jira answers a question Jira itself cannot: "Who can access this project — and why?" For any project it resolves the full permission grid to real people and explains every grant in plain English — "Jane can Edit Issues because she is in the jira-developers group, which the Software scheme grants Edit Issues." Around that it adds reverse lookup ("where is this group used?"), risk findings, issue-security visibility, point-in-time history with drift detection, and audit-ready access-review campaigns.
The app is built on Atlassian Forge with zero data egress — nothing ever leaves your Atlassian tenant — and every answer is computed as the person using it, so the app can never reveal more than that person is already allowed to see in Jira.
2. Getting started
2.1 Installation
- Install Permission Auditor for Jira from the Atlassian Marketplace.
- Grant the requested read-only permissions when prompted. The app requests no write access and runs entirely on Atlassian infrastructure.
- Open
Apps → Permission Auditorin the Jira navigation for the site-wide Audit Hub, or open any project'sProject settings → Permission Auditorfor that project's access explorer.
2.2 Entry points
- Audit Hub (global page)
- Under
Appsin the Jira navigation — the site-wide console: the access-graph index, reverse lookup, natural-language Ask, and access-review campaigns. Requires the Administer Jira global permission. - Project access explorer
Project settings → Permission Auditor— the per-project permission grid, explanation chains, risk findings, and history. Available to anyone who can administer that project.- Issue panel
- "Who can see this issue" on any issue — the issue-security explainer and comment-edit audit summary.
- Admin page
Jira Settings → Apps → Permission Auditor— comment-capture control, retention, and diagnostics. Jira admin permission required.
2.3 Who can use what
The two axes reflect how Jira scopes access. Site-wide tools (the access-graph index, reverse lookup, Ask, and campaigns) read across every project, so they require the Administer Jira global permission. The per-project explorer resolves a single project as you, so any project administrator can use it on their own projects — and it shows only what your own Jira permissions allow, marking anything hidden with an "ask your admin" note rather than guessing.
3. The project access explorer
Open Project settings → Permission Auditor. The app resolves the project's permission scheme, expands every group and project role to named people, filters to users who actually hold Jira product access, and renders the result.
3.1 The permission grid
The grid has one row per user and one column per Jira permission (Browse Projects, Edit Issues, Administer Projects, Delete Issues, and the rest). Sensitive permissions are marked with a lock. A filled cell means the user holds that permission; a badge such as ×3 shows how many independent paths grant it. The header states the scheme in force and the number of users resolved.
3.2 Explanation chains — the why
Click any filled cell to open its explanation chain: a plain-English sentence plus the step-by-step trace of how the user got the permission (direct grant, group membership, project-role actor, or a role reached via a group). When a user qualifies more than one way, all paths are listed with a warning that removing one will not revoke access while the others remain — the trap manual audits fall into.
3.3 Why NOT — diagnosing missing access
Ask about a permission a user lacks and the explorer proves the negative and shows the nearest miss: "Jane cannot Edit Issues here. Closest path: add her to group jira-developers, which the scheme grants Edit Issues." This works for any user, any permission, at the project level — what Jira's built-in Permission Helper cannot do in bulk and never for project administrators.
3.5 Dormant grants
A grant to a user who has no Jira product access is inert — the app labels it dormant rather than counting it as live access. Dormant grants are exactly what an access review should prune, so they are called out explicitly.
4. Risk findings
Below the grid, the explorer lists risk findings graded critical / high / medium / low. The rules include public or "any logged-in user" grants, an unusually large number of project administrators, a single (or no) project administrator, redundant direct grants, dormant grants, and apparently-inactive (archival-candidate) projects. Findings are typed and traceable — there is no opaque score to argue with.
5. Reverse lookup
The Audit Hub answers questions across every project at once. It works from an access-graph index the app builds by resolving each project you can see.
5.1 Building the access-graph index
Click Build index. The index is built as you, in your browser, one project at a time — keep the tab open while it runs; you can stop and resume any time. Because it is computed with your own permissions, it never contains anything you could not see yourself. Rebuild it whenever you want a fresh view.
5.2 Where is this group used?
Enter a group id to see every project, permission, and affected-user count the group grants access to — the report to run before you edit or delete a group, so you never remove access blindly.
5.3 What can this user access?
Enter an accountId to see every project a user can reach and the permissions they hold in each — the cross-project access profile Jira does not provide, ideal for offboarding and access reviews.
6. History, drift & alerts
6.1 Snapshots
From a project's explorer, click Capture snapshot to freeze its resolved access as a point in time. Snapshots are retained in the app's Forge storage — independent of Jira's own audit-log retention, which is limited and, on lower plans, absent.
6.2 Comparing snapshots
Compare last two produces a drift feed in plain past tense: "On this date, Bob GAINED Edit Issues (via jira-developers)." Each change is graded, and new admins or new public grants raise an alert in the in-app notification centre. This is the resolved impact of a change — the join Jira's configuration audit log never makes.
7. Issue security & the issue panel
Issue-level security is the blind spot most tools ignore. The Who can see this issue panel on any issue reports whether the issue carries a security level and, when your permissions allow, resolves that level's members to named people. If the full member list requires admin access you do not have, the panel says so honestly rather than implying the issue is invisible. At the project level, the explorer inventories the security scheme's levels and flags dead levels (no members) and decorative levels (no one who can browse the project is a member).
8. Access reviews
8.1 Running a review
- In the Audit Hub, open Access reviews and start a review for a project. The scope is frozen at launch so the review is a stable point-in-time set.
- Work down the rows, marking each grant Approve or Revoke. Progress shows a traffic-light indicator; unchanged approvals from a prior review carry forward so you only re-examine what changed.
- When every row is decided, click Sign off.
8.2 Tamper-evident evidence
Sign-off produces an evidence bundle whose entries are linked in a SHA-256 hash chain: any later edit to a historical entry breaks the chain, and the app verifies it on export. The result is an audit-ready record for ISO 27001 A.5.18 or SOC 2 CC6 access reviews. (These templates support your evidence collection; they are not a certification of compliance.)
9. Ask (natural-language)
The Audit Hub's Ask box accepts plain questions — "who can administer PROJ?", "where is group dev-team used?" — and routes them to the right engine. Answers are computed deterministically by the resolver; there is no AI inference and no data leaves Atlassian.
11. Privacy & security
- Runs on Atlassian. Built on Forge; all compute and storage are Atlassian-hosted. No remote servers, no external network calls — zero data egress.
- Read-only. The app requests only read scopes plus storage and the Privacy API. It never writes to your Jira configuration; remediation is offered as deep links to the native admin screens.
- Computed as you. Every Jira read runs with your permissions, so the app cannot see more than you can. Site-wide tools require Administer Jira; per-project tools require project admin.
- Data residency. All app data is stored in Forge storage and inherits your Jira site's residency region automatically.
- Personal data. The app stores Atlassian account IDs (never names or emails, which are resolved live at display time) and, if comment audit is enabled, comment bodies. It participates in Atlassian's Privacy API: account IDs are reported weekly and scrubbed when an account is closed.
- Uninstall. All app data for the installation is removed on uninstall; an admin "purge" action is also available.
12. Troubleshooting
| Symptom | Cause & fix |
|---|---|
| "Access hidden for your account" in the project explorer | You lack permission to read that project's scheme. Ask a project or Jira admin, or open a project you administer. |
| Site-wide tools show "need Jira admin" | The index, reverse lookup, Ask, and campaigns require the Administer Jira global permission. Use the per-project explorer instead. |
| Reverse lookup says "build the index first" | Open the Audit Hub and click Build index; keep the tab open until it completes. |
| A user shows as an account ID, not a name | The account may be deactivated or an app/bot account without a resolvable display name. |
| Issue panel can't list a security level's members | Listing members requires admin access; the panel confirms you can see the issue and notes that the full list needs an admin. |
13. Support
- Support portal: chefstackz.com/support
- Email: support@chefstackz.com
- Privacy Policy: chefstackz.com/privacy
- Terms of Use: chefstackz.com/terms
We typically respond within one business day.
10. Comment-edit audit
Jira does not keep a history of edited or deleted comments. Permission Auditor captures comment create, edit, and delete events from the moment it is installed, so you can later see that a comment was changed, by whom, and what it said — a common compliance requirement. Deleted-comment bodies are visible to Jira admins only, and comment history is shown only to users who can see the comment in Jira. Capture can be turned off site-wide on the admin page, and stored history follows the configured retention window.