Doorman for Jira
Answers "who can do what in this project, and since when" from inside Jira settings, for the site admin who has to show it to an auditor.
- One row per person per project: role, the group or grant that gives it, and the permissions it carries.
- A change trail that keeps audit log records past their native retention and fills gaps with hourly diffs.
- Access review rounds with recorded decisions, and an evidence pack for the auditor.
- Set-up is one click. Snapshots run every hour; on most sites the first report is ready within the hour, or in about a minute if you run one by hand. Very large sites finish over several runs.
Install
Install from the Atlassian Marketplace as a Jira site administrator. The app asks for read scopes, app storage, the personal data reporting scope, and manage:jira-configuration, which Jira requires before an app may read application roles, global settings and the audit log; the app uses it only to read. It writes nothing to your Jira configuration, and its code calls only Atlassian APIs.
Open the app
In Jira, open Settings, then Apps, then Doorman in the left sidebar. Only Jira administrators, people with the Administer Jira permission, can open it.
First snapshot
Every hour the app reads the native audit log and the global settings. It reads access again (users, groups, project roles and permission schemes) when the audit log shows activity, and reads everything once a day. On first open you will see "No snapshot yet". Click Run snapshot now, wait a minute, and reload. The line under the tabs shows when the snapshot ran and how many users, groups and projects it covered.
Access tab
One row per person per project: the roles they hold, how they hold each one (direct, through which group, or as project lead), and the permissions the person holds in that project under its permission scheme. Grants that depend on the issue, such as its reporter, its assignee or a user or group picker field, are one row per project marked as issue roles. Filter by any word, pick a project, a permission, project admins only, broad grants (anonymous, any logged-in user, everyone with a product), or app and customer accounts. Export CSV downloads the filtered rows with account ids included.
Click a person's name for everything that account holds: groups, product access, and every project role with its permissions.
The Fix column links to the Jira page that changes the row: project permissions, project roles, or the permission scheme. The app itself never writes to Jira.
Findings
Above the table, the app counts what an admin would flag by eye: inactive accounts that still hold access, public access beyond browse, people who administer more than three projects, app or customer accounts with admin rights, and seat-granting groups with no members. Click a finding to filter the table to it. The same counts feed the dashboard gadget.
Point in time
The first complete crawl of each month is kept for twelve months. Pick a month next to the snapshot badge to see who had what access then, with groups expanded to members. Run snapshot, the evidence pack and reviews are hidden while an archived copy is shown; fix links still open the current Jira page.
Evidence pack
Evidence pack on the Access tab builds one zip: the access matrix, the findings, and every change record in a date range, each as CSV, plus a manifest with a SHA-256 digest per file, who generated it and when. An auditor can recompute the digests to confirm nothing was edited after export, and the export log on the Reviews tab shows the digests the app produced.
Fields tab
Every field on the site with its type, the projects its contexts cover, how many screens and saved filters use it, and when Jira last saw it used. Two findings: custom fields that share a name and type, and custom fields on no screen, in no filter and never used. The Fix link opens the field's context page. The inventory is read by the daily crawl, and changes to it appear on the Changes tab.
Product access tab
The groups that grant Jira Software or Jira Service Management access, their member counts, which are default groups for new users, and product users against seats bought. This is where seat spend comes from.
Changes tab
A running record of configuration changes from three sources, each labelled:
- event: Jira told the app the moment it happened, with the actor's account id.
- audit: a copy of a native Jira audit log record. Kept after Jira's own retention expires.
- snapshot: a difference between two hourly crawls, for settings the native log does not record.
The Actor column says how the app knows. A name alone came from the event or the audit record. "Inferred from audit log" means the app matched a change to an audit record for the same object within ten minutes. "Unknown" means it does not know and will not guess.
Reviews tab
An access review round names projects, a reviewer and a due date. Each person's access in those projects is listed once per role, and the reviewer marks it keep or revoke with a note. Decisions are stored with the deciding account and time and are never edited; a later decision on the same row is added, not written over. Rows with no decision in the previous closed round for the same project are marked new, so a quarterly review only has to look at what changed. Export CSV shows the file's SHA-256 digest after download, and the app keeps an export log with every digest it has produced, so an auditor holding a file can ask whether the app made it. Any site administrator can record decisions; each decision and each export records who. Revoke is a decision and a fix link, the app does not change Jira.
Limits tab
Jira Cloud stops admins adding fields, work types, statuses, workflows and more once a space, field or scheme reaches its limit. The Limits tab measures the ten limits Jira enforces and four recommended guardrails on the daily crawl, and for each one names the space, field or scheme closest to it, its share of the limit, and the next four behind it.
Hygiene tab
Permission, workflow, work type, work type screen, field configuration, notification and priority schemes no project uses, and workflows and statuses nothing uses, from the daily crawl. Defaults, the system workflow, draft schemes and team-managed configuration are never listed, and if a workflow scheme draft could not be read the workflow and status lists say so instead of guessing. A workflow inspector shows a workflow's statuses and transitions and compares two workflows. A per-project configuration report downloads as Markdown. The app only reads: check each item before deleting it.
Dashboard gadget
Add Doorman: changes and findings per week to any dashboard. It shows this week's change count, open findings at the last snapshot, and twelve weeks of both. Any dashboard viewer can see the two numbers; the tables and names stay on the admin page.
What the app cannot see
- When a user last logged in. Atlassian does not expose it to apps.
- Admin webhooks, work item archiving, issue layout edits, app installs, backups, and Jira Service Management feature toggles. No API or event exists for them.
- The native audit log on the Free plan, where Atlassian does not provide it. Events and snapshot diffs still work.
Large sites
A crawl has a fourteen-minute budget. On a very large site the access crawl saves its progress at the end of the budget and the next run carries on from there; until it finishes, the page shows the previous snapshot and says the run was incomplete. Tell us your project and user counts through support and we will look at it.
Data and privacy
Everything the app stores lives in Atlassian Forge storage in your site's region. After the app is uninstalled, Atlassian keeps its storage for 28 days, then deletes it. To recover it, ask us within 21 days of uninstalling; reinstalling alone does not bring it back. Details in the privacy policy.