Permissions and security

The short version

• Change history is read in your browser, as you. If Jira will not show you a work item, the app cannot show it either. The exceptions, scheduled reports, a few lookups that need a permission most people lack, and background jobs, are described below.
• Restoring and reverting write as you, so Jira enforces your create, edit and transition permissions, and the audit trail names you.
• Deleted items are filtered by the projects you can browse, checked as you on every request. A secured one is shown only when Jira confirms you are in its security level. Jira administrators see every one.
• The app declares no egress permission. Forge blocks external calls at the platform level, so the app itself never sends your Jira data outside Atlassian, to the vendor’s servers or anywhere else. If people use the app’s Rovo agent, Atlassian Rovo writes its answers under Atlassian’s own terms, using Atlassian’s sub-processors.
• The vendor sees the operational logs described under Logging, which an organization admin can switch off, and the usage metrics and installation details Atlassian gives every app’s developer, which hold no Jira data.
• Only the data the features need is stored, inside your own Atlassian site.

How each action is authorised

Where the app acts as itself

Some work has no person behind it, so it runs with the app’s own access rather than a user’s:

See Scheduled reports for how a schedule is kept within its creator’s reach.

Feature permissions

An administrator decides who can use each of six features (history reports, export, revert, deleted items, security scanner, viewer history): everyone, Jira admins only, or named Jira groups. The security scanner starts as Jira admins only, because it gathers every secret a person can see into one list; the other five start open to everyone. See Admin settings for exactly what each one controls.

Be precise about what this is. Wherever the app’s backend serves the data, the check runs on the server:

• Deleted items and viewer history, which read the app’s own storage (on Atlassian’s cloud, inside your Jira site. The app sends no data outside Atlassian, and nothing is stored on Astrospray’s servers.).
• History reports for saved views, the group lookup behind the Changed by group filter, and scheduled reports.
• Export for signing an export and for scheduled reports, which deliver a file.
• The Rovo agent’s three actions, each checked against the matching feature.

A work item’s own history and comment history aren’t among the six features: they follow Jira’s own permissions for the work item and each comment.

Reports, exports, revert and the scanner otherwise run in your browser against Jira’s own API. There the restriction is applied in the app’s interface: a blocked person gets no Reports tab and no download or revert buttons, and the Changes tab, the issue search action and the dashboard gadgets show a short note instead of any data. Jira’s own permissions remain the real boundary on the data itself, so nobody gains access to Jira data through the app that Jira itself would not give them.

If the app can’t load your permissions (a network or service error), it fails closed: reports, exports, revert, deleted items, viewer history and the scanner stay shut, and the page says to reload. An error never opens a feature an administrator has restricted.

What is stored, and for how long

Scheduled report files and their summary comments are stored in Jira itself, on the work item each schedule delivers to, like any other attachment and comment. A dashboard gadget’s settings are saved by Jira with the dashboard.

Closed Atlassian accounts. Every week the app reports the Atlassian account IDs it holds to Atlassian’s personal data reporting API, as Atlassian requires of apps that store account IDs. When Atlassian answers that an account has been closed, the app erases that person’s view records and their first-run guide progress, removes them as assignee, reporter and “deleted by” on work item snapshots and deleted-item records (and from user fields captured there), and shows them as Former user on comment versions, signed-export records (including the names in their Report line), saved views and scheduled reports, in the Changed by filters of saved views, schedules and signed-export records, and in @mentions in captured descriptions and fields. When a person’s profile changes, the stored display name is refreshed in the same places. Captured comment text is kept as plain text, so a name written or @mentioned in a comment stays as it was, and so does an account ID written into a saved JQL query (in a saved view, a schedule or a signed-export record). User fields in snapshots keep only the account ID and display name, never an email address.

Forge storage is kept on Atlassian’s cloud, separately for each site. If your site is pinned to a data residency region, the app’s storage is kept in that region too.

Scopes

The app requests eleven Atlassian scopes and nothing else:

There is no permissions.external entry, which is what makes the “no egress” statement enforceable rather than a promise.

Logging

The app’s backend logs operation outcomes, error types and counts, and it records work item keys, comment identifiers and scheduled report names so a failed operation can be traced. The app does not write field values, summaries, descriptions or comment text to its logs. When a call fails, the error message Jira or the platform returned is logged, shortened to a few hundred characters. Logs are held by Atlassian on its own schedule. Atlassian shares an app’s logs with its developer by default, through Atlassian’s developer tools; an organization admin can switch this off in Atlassian Administration, under Connected apps. Atlassian also gives every app’s developer usage metrics and installation details, for example how often the app’s functions run and fail, and which sites it is installed on. These hold no Jira data.

Exports

Export files are built in your browser from the report data it has already loaded, which can be more rows than the table shows at once, and saved to your own machine. They are not uploaded anywhere. Signing an export sends only its fingerprint and the details listed above to the app’s storage on your site, and saves a short receipt to your machine. An unmasked scanner export contains real secrets, and the file itself says so in its header; handle it accordingly.

Uninstalling

Uninstalling ends the app’s access to its Forge storage for your site, including snapshots, deleted-item records, comment versions, view records, saved views, scheduled reports, signed-export records and settings. Atlassian keeps that storage for 28 days after uninstall, then deletes it. A reinstall starts empty. To have it reconnected to your earlier data, contact us promptly: Atlassian must receive the request within 21 days of uninstalling. Work items you already restored stay in Jira, because they are ordinary Jira work items, and so do scheduled report files and comments already delivered.

To remove comment versions and view records without uninstalling, an administrator can use Erase captured tracking data on the admin page. See Tracking.

Limitations

• Deleted-item visibility is checked per project and per issue security level, as the person asking. A secured item is shown only when Jira confirms they are in its level: the app counts the work items at that level in that project, leaving out ones they reported or are assigned, once as them and once as the app, and the two counts must match and be above zero. If Jira can’t confirm it, for example because no other work item is left at that level, the item stays hidden, and the list says something was left out without naming it. Jira administrators see every secured item. A deletion the app only partly captured (the work item was never snapshotted, and Jira’s delete event doesn’t carry its level), or one the app could no longer read after a later change (so its last snapshot may be out of date), is shown only to Jira administrators. Running the backfill after installing snapshots every work item the app can read. A work item at a security level that leaves out the app can’t be snapshotted, so if it is deleted it may not be captured at all, or only partly.
• When a whole project is deleted permanently, Jira sends no deletion for each of its work items, so they don’t appear under Deleted items, and their snapshots stay in the app’s storage until the app is uninstalled. Closed accounts are still erased from them each week. A project moved to the trash and restored needs nothing: Jira brings its work items and comments back.
• The app is not a backup product. It captures snapshots for restore. A restored work item gets a new key, today’s date and the person restoring as its reporter, and it doesn’t bring back attachments (the files are deleted with the work item), links, logged work or the change history. Comments come back only as copies re-posted by the person restoring.
• The vendor has no access to your Forge storage and no endpoint to receive your data, so vendor-side deletion requests are not applicable. Deletion is a Jira and Forge operation. The vendor sees the operational logs described under Logging, which an organization admin can switch off in Atlassian Administration under Connected apps, and the usage metrics and installation details Atlassian gives every app’s developer (for example how often the app’s functions run and fail, and which sites it is installed on), which hold no Jira data.
• Answers from the app’s Rovo agent are written by Atlassian Rovo from what the app’s actions return, under Atlassian’s own terms, using Atlassian’s sub-processors. The app itself sends nothing outside Atlassian.

Further reading

• Privacy policy
• Security and data handling
• Admin settings
• FAQ