The Jira permissions this app asks for
This is the page a security reviewer asks for: a line by line account of what the app can touch in Jira, and why each line is there. The app asks for six permissions and no more. Five of them are reads. The sixth writes one flag.
One of the six is classed by Atlassian as sensitive, and it is the one the whole product rests on. We would rather lead with it than bury it: the app reads the reporter's email address, and that address is what goes to Attio to find the record.
#The six, in full
Permission | Atlassian's name for it | What the app does with it |
|---|---|---|
Read issues | read:jira-work | Reads the request the viewer is looking at, as that viewer. This is the gate on everything else: a viewer who cannot open the issue gets no card and no lookup. |
Read users | read:jira-user | Checks a viewer's Jira group membership when a project restricts the card to named groups, and resolves the name shown beside each row of the site connections list. |
Read service management requests | read:servicedesk-request | Declared for service management request context. Everything the card puts on screen comes from Attio, so no Jira request content reaches the card itself. |
Read a user's email address | read:email-address:jira | Reads the reporter's address on the server, once the issue read above has succeeded. It is the value that finds the record in Attio. Atlassian classes this permission as sensitive. |
App storage | storage:app | The app's own storage: the project's settings, its short-lived caches, and the encrypted secret store that holds the Attio key. |
Write one project property | write:project.property:jira | Writes the single non-secret flag that tells Jira whether the card may appear on this project's issues, and in which of the three places. |
There is no permission here to create, edit or delete anything in Jira. The app adds no comment, sets no field, makes no transition and touches no attachment. The one project flag is the whole of its write access, and the app is read-only against Attio as well.
#The email permission, and why the product does not work without it
Jira does not include the reporter's email address in the issue itself. Without permission to read email addresses there is nothing to match a CRM record against, and the card can only ever say "No email address is available for this reporter." on every request, forever.
State it plainly The reporter's email address leaves Atlassian. It is sent to Attio as the value the record is looked up by: the whole address when a project matches people, or only the part after the @ when it matches companies by domain. The app declares this to Atlassian as a transfer of end-user data rather than filing it as ordinary infrastructure traffic.
What the app does not do with it is the subject of its own page, but in one line: the address is used on the server, is never returned to the browser, is never printed on any screen, is never written to a log, and is never stored in readable form. Every sentence the card writes says "this reporter" instead of naming them, which is what Atlassian's own guidance requires of an app approved to read addresses.
#Reading the issue first is the design, not a detail
The order of those two reads is fixed. The app reads the issue as the viewer, takes the reporter's identity from Jira's answer, and only then asks Jira for that account's address as the app. It never takes the reporter from anything the browser sends.
The reason is specific. Jira's email endpoint is exempt from a tenant's own app access rules, so it cannot act as a gate by itself. The issue read is the only thing binding an address read to an entitled viewer looking at an issue that person actually reports.
#The one write, and everything that is in it
The flag written on the Jira project holds two things and nothing else: whether the project is ready or disconnected, and which of the three placements were chosen. That is what lets Jira hide the card in projects that have not finished setup, and it is why disconnecting takes the card off every issue in one move.
Why the flag is so thin A Jira project property can be read by anyone who can browse the project, and can be read anonymously. So the flag deliberately carries no workspace name, no record type and no hint about what the connection is to. Every real setting lives in the app's own storage, where only the app can reach it.
#A new permission ships before your administrator approves it
The app uses Atlassian's rolling release model. A version that needs a new permission reaches every existing installation straight away, and the new permission sits pending approval in Admin Hub rather than blocking the upgrade. Anything that depends on that permission stops working quietly until a site administrator approves it.
There are two visible symptoms, and neither of them says "permission" on the issue view. The first is every card reporting that no email address is available. The second is a project that saves its settings and never shows a card, which the settings page reports at the top of the tabs under "Saved, but the card is not switched on yet": "Your settings are stored. Jira would not let this app update the project, which is what makes the card appear on issues. A Jira site administrator may need to approve this app's new permissions in Admin Hub. Choose a placement again once they have."
#A few things worth knowing
"No email address is available for this reporter." is not a diagnosis. A pending permission, a deleted account and a profile that keeps its address from apps all produce that one sentence, and the app deliberately does not guess which of them happened.
Setup can be complete and correct and the card can still appear nowhere, because the project flag write was refused. The settings page says so in a banner. The issue view has no way to tell anybody, because from its point of view the project is not switched on.
Approving a pending permission is a site-wide action taken by a Jira site administrator in Admin Hub. The project administrator who configured the project usually cannot do it, so a project can be finished by somebody who is not able to switch it on.
#Related
Five reads, one write, and the write is a flag with two fields in it.
