User Guide

Copyright 2026 Matify. All Rights Reserved.

This guide covers every tab in Access Auditor for Jira, in the order they appear: Overview, Findings, Explorer, Schemes, Changes, Exports, Settings, Diagnostics. Read Getting_Started.md first if you have not yet run a scan.

Vocabulary used throughout this guide

Holder — whatever a permission grant names as the recipient: a user, a group, a project role, an application role, or a symbolic holder such as "the current assignee".

Symbolic holder — a holder that does not name a fixed set of people. Current assignee, reporter, project lead, and a user or group custom field value all resolve differently depending on the issue in front of you. Access Auditor labels these resolves per issue rather than guessing who they are. See Known_Limitations.md for the full list.

Granted via — the chain of configuration that connects a holder to a permission: for example, a permission scheme grants Administer projects to the Administrators project role, and a named user is a member of that role. The app shows every link in that chain, not just the endpoints.

Privileged group signal — the reason a group is treated as an administrator group. Jira Cloud exposes no API for global permission grants, so Access Auditor cannot read who your site administrators are. It instead marks a group as privileged when at least one of three signals applies: the group grants product access through an application role, the group holds Administer projects in a permission scheme, or the group's name matches an Atlassian default administrator naming convention (a heuristic, labelled as such everywhere it appears).

Capability degradation — when a scan asks Jira for something and receives a restricted or forbidden response rather than the normal one. The app records this per capability rather than silently showing fewer results.

Incomplete scan — a scan is marked incomplete when any capability it depends on came back degraded or forbidden, or when a site-wide collection cap was reached. The Overview tab tells you which part was affected.

Overview

Answers: is my site's access configuration healthy right now, and did the last scan see everything it needed to?

• Open findings, grouped by severity: critical, high, medium, low, info.
• The last scan's metadata: when it ran, how long it took, how many Jira

API calls it made, and whether it was marked incomplete.

• Run scan now, with live progress, for starting a scan by hand between

scheduled runs.

• The top findings, so you do not have to open the Findings tab to see what

needs attention first.

• A findings trend across recent scans, so you can see whether your open

finding count is going up or down over time.

• A warning banner when a scan could not read something it needed. Follow

it to Troubleshooting.md.

Findings

Answers: what, specifically, is wrong, and what should I do about it?

Filter by severity, rule, project, status or free text. Each finding shows:

• A plain-language summary of the configuration the rule detected.
• A remediation — what to consider changing.
• An evidence list showing exactly what the app read to reach its

conclusion.

• Where Jira supports it, a deep link straight into the relevant Jira

administration screen.

You can acknowledge, resolve or reopen a finding, each with an optional note. An acknowledged or resolved finding stays in that state across future scans until the underlying configuration changes, or until the acknowledgement expiry you set in Settings elapses.

The twelve findings

Every finding on this tab is generated by one of the following rules. Names and default severities are fixed; only the sensitivity profile changes which permissions count as sensitive for rules that check permission grants.

• R1 fires when a permission is granted to the "Anyone" holder, which

can expose project data to users who are not logged in wherever the site and project allow anonymous access.

• R2 fires when a destructive or administrative permission is granted

to every logged-in user, which removes any separation of duties.

• R3 fires on a filter or dashboard shared beyond the team, which can

expose issue summaries or metrics outside the organisation.

• R4 fires when a deactivated account remains in a project role or an

administrator group; the access returns in full if the account is ever reactivated.

• R5 fires when a group carrying administrator access is larger than

your configured large-group threshold, or contains inactive accounts.

• R6 fires on a permission scheme that no project uses.
• R7 fires on two permission schemes that differ by only a small number

of grants and are usually candidates for consolidation.

• R8 fires on a project that is broadly readable and has no issue

security scheme, so there is no way to restrict an individual sensitive issue within it.

• R9 fires when a project's Administrators role has no members, which

means every change to that project escalates to a site administrator.

• R10 fires when Administer projects is granted to a group larger

than your configured large-group threshold.

• R11 fires on a sensitive permission granted through a user or group

custom field, because that grant resolves per issue and cannot be reviewed from configuration alone.

• R12 fires on an archived project that still carries a broad grant,

because the grant remains in place if the project is ever restored.

Explorer

Answers: what does this specific project, group or person actually reach? Three modes:

• By project — the permission matrix for that project: every

permission, its resolved holders, and the granted-via chain for each.

• By group — every project and permission that group reaches, across

the whole site.

• By user — the same as group mode, for one person, including which

group carried each permission they hold.

In every mode, select View access on a row to open its detail; the list is replaced, and a Back to all … control returns you to it.

How to read the permission matrix

1. Find the project in the list and select View access. The matrix

replaces the list; Back to all projects returns you to it. Each row is one Jira permission (for example Browse projects or Administer projects).

1. The Granted to column lists everyone and everything that can

exercise that permission in that project: named users, groups (with a member count), project roles, application roles, and holders that resolve per issue.

1. Under each holder is its granted via chain, always visible — nothing

to expand. For a group member it typically reads scheme → grant → group → member. For a project role it reads scheme → grant → role → actor.

1. A holder marked resolves per issue (assignee, reporter, project

lead, or a custom field value) has no fixed member list; the chain explains the grant, not a name.

1. A holder marked no members in this project is a project role that

the scheme grants a permission to, but which nobody holds. The grant is real and the access is not — worth knowing before you assume a role covers a permission. Finding R9 raises this for the Administrators role.

1. A holder marked deactivated is a disabled account that still holds

the permission — this is exactly what finding R4 flags.

1. A note above the matrix reports Atlassian app accounts that also hold

access. They are excluded from the rows because they are installed apps rather than people, and their count is shown so the exclusion is visible.

1. Team-managed projects show no matrix here; see

Known_Limitations.md.

Schemes

Answers: what do my permission schemes actually contain, and are any of them redundant?

• Every permission scheme, its grant count, and which projects use it.
• A detail view of a scheme's permissions and resolved holders.
• Detection of near-duplicate schemes (finding R7), with a match

percentage and a list of exactly what differs on each side.

Changes

Answers: what changed since the previous scan?

Filterable by change type. Changed sharing and changed scheme bindings show a before → after comparison. This tab reports what changed, never who changed it or precisely when — Jira's audit log is not read by this app. See Known_Limitations.md for why. The first scan after installation always shows no changes, because there is nothing yet to compare it against.

Exports

Answers: how do I get this data out for a report or an auditor?

Three exports, each available as CSV or JSON:

• Findings
• The full permission matrix
• The change list

If a download does not start, see Troubleshooting.md for the Copy to clipboard fallback.

Settings

Configures how the app scans and what it keeps:

The strict profile treats a wider set of permissions as sensitive for rule R2 — for example editing, transitioning, assigning, resolving and closing issues, and managing watchers, in addition to the permissions the standard profile already treats as sensitive. Expect more R2 findings on the same site under strict than under standard.

Every value you set here is re-validated on the server before it is stored; the browser is not trusted with this decision.

Below the settings is the Danger zone, which deletes everything Access Auditor has stored for your site — every scan, finding, change record and acknowledgement — after showing you a count of what that is and asking you to confirm in writing. The app stays installed and scans again afterwards. Nothing in Jira is touched.

Diagnostics

Answers: what is this app doing, and what do I send to support if something goes wrong?

• App version, environment and licence state.
• A summary of the last scan.
• The capability matrix — whether each Jira capability the scan depends on

responded normally, was degraded, or was forbidden on your site.

• An on-demand capability check you can run without waiting for the next

scheduled scan.

• A copyable support report, built to contain no personal data and no

credentials, for sending to mira.maty@web.de.

See also

• Permissions_and_Security.md
• Privacy_and_Data.md
• Known_Limitations.md
• Troubleshooting.md