What Vouchline reads, and what it does not

Vouchline reads the permission model of your Jira Cloud site. It does not read work items, comments, attachments or worklogs, it changes nothing in Jira, and it sends nothing outside your Atlassian site.

Read-only, by construction

Every permission the app requests is a read scope, plus storage for its own data. There is no write scope, so the app cannot grant, change or remove a permission even if it wanted to. A decision of "to revoke" is a recorded decision; removing the access is done by your administrator in Jira.

Several of the listed scopes (read:avatar:jira, read:issue-type:jira, read:field:jira and similar) are there because Jira requires a scope for every field present in a response, including fields the app does not use. The app never requests read:jira-work, the scope that gives access to work item content.

The four ways access is granted in Jira

Vouchline reads all four:

1. Product licence — which groups give access to a Jira product.
2. Project role — accounts and groups placed in a role in a project.
3. Permission scheme — permissions granted to roles, groups, single users or everyone.
4. Site and product administration — which accounts administer the site or Jira.

The limits, stated plainly

A review is only as good as its scope, so this is what the scope is:

• Administration is checked for accounts that already appear somewhere in the permission model. An administrator who is in no project role, no scheme and no group that Vouchline reads is outside the review. The report says so.
• Group membership does not prove where a permission comes from. Jira Cloud does not expose, through its REST API, which group grants site or product administration. When a rule reports that a group contains administrators, that is an indication for the reviewer, not a verdict.
• Rules can be switched off, and rules can fail to evaluate. In both cases the report lists the rule as not evaluated, with the reason. A rule that could not run is never shown as "zero findings".
• A scan can be partial. If Jira refuses part of the data, the snapshot is marked accordingly, creating a review from it requires an explicit confirmation, and the fact is recorded with the review and printed in the report.
• Empty groups are counted, not listed. A group with no members is reported as a number in the rule's note rather than as an item to decide.
• Only Jira. Confluence and other Atlassian products are not covered.

Why Vouchline itself appears as a Jira administrator

Atlassian adds the account of a Forge app to the groups that match the scopes the app declares. As a result the Vouchline app account holds Jira administration, and it holds a role in every project.

• Nobody signs in as this account. It acts only through the scopes above.
• Vouchline leaves its own account out of the findings about product access and project roles, because Atlassian puts it there in every project and the finding would be pure noise. This exclusion is stated in every report.
• Vouchline does not leave its own account out of the finding about administration. An access review tool that exempted itself from the one rule about administrators would defeat its own purpose.

Personal data

Vouchline stores account identifiers, never people's names. Names are fetched from Jira at the moment they are displayed, on behalf of the person looking, and are written into the files you download — not into the app's storage. See the Privacy policy.

The one place a name can enter the register is a reviewer's justification, which is kept word for word. The reviewer screen asks reviewers to describe people by role, not by name.