Security and data handling: UndoTrail for Jira

Architecture in one picture

Your browser (Jira page)                    Atlassian cloud
┌───────────────────────────┐              ┌──────────────────────────────┐
│ App UI (Forge Custom UI)  │── as you ───▶│ Jira REST API                │
│  reads history, exports,  │              │  (your permissions apply)    │
│  reverts                  │              └──────────────────────────────┘
└─────────────┬─────────────┘
              │ invoke()                    ┌──────────────────────────────┐
              ▼                             │ Forge functions + storage    │
        Forge resolver ───────────────────▶ │  snapshots, saved views,     │
        (Atlassian-hosted Node.js)          │  settings, comment/view logs │
                                            └──────────────────────────────┘
                     ✗ no path out of Atlassian: no egress permission

How permissions are enforced

• Reading history happens in your browser as you (requestJira). If Jira won’t show you a work item, the app cannot show it either. There is no service account and no elevated read of history.
• Restoring a deleted work item creates it as you, so Jira enforces your create permission and the audit trail names you, not the app.
• Reverting a change edits as you, so Jira enforces your edit permission and its own workflow rules.
• Listing deleted items reads the app’s own storage. Before returning anything it checks, as you, which projects you can browse (/rest/api/3/permissions/project) and filters to those. A secured item is shown only when Jira confirms you are in its security level, and Jira administrators see every one.
• Admin-only actions (retention, tracking, permissions, access codes, backfill) check the Jira ADMINISTER permission on every call, server-side.
• Optional group restrictions: an admin can restrict any feature (reports, export, revert, deleted items, security scanner, viewer history) to named Jira groups. Be precise about what that means: wherever the app’s backend serves the data (deleted items, restore, viewer history, saved views, signed exports, scheduled reports and the Rovo agent’s actions) the restriction is enforced in the backend and cannot be bypassed. Reports, exports, revert and the scanner otherwise read Jira directly from the browser as the user, so there the restriction removes the feature from the app rather than adding a second lock; Jira’s own permissions are what actually bound the data in those cases, and they apply regardless.

What the app stores, and for how long

See the privacy policy for the full table. In summary: snapshots of work items (so deletions are recoverable), deleted-item records with an automatic expiry (default 90 days), optional comment versions and view records, saved views and settings. Change history itself is never stored. It is read live.

Logging

Backend logs record operation names, error types, counts and identifiers (a work item key, a comment id, a project key, a scheduled report’s name). When a call fails, the error message Jira or the platform returned is logged too, shortened to a few hundred characters. No field values, summaries, descriptions or comment text are ever logged. Forge logs are visible to the app’s developers only through Atlassian’s developer tools. Atlassian shares them by default, and an organization admin can switch this off in Atlassian Administration, under Connected apps. They are retained by Atlassian on its own schedule. Atlassian also gives every app’s developer usage metrics and installation details, such as how often the app’s functions run and fail, and which sites it is installed on; these hold no Jira data.

Secrets

The app holds no customer credentials. It has one secret of its own: an HMAC key used to sign free access codes, stored as an encrypted Forge environment variable. It never signs or verifies anything on behalf of a customer.

Development and release practice

• Every change ships through typecheck → unit tests → build → manifest lint; the test suite covers the pure logic (history normalisation, exports, revert planning, restore mapping, permissions) with in-memory fakes, plus browser-level tests of the UI.
• Dependencies: the app’s runtime dependencies are Atlassian’s own Forge packages. Exports (Excel, PDF, ZIP) are written in-house specifically to avoid pulling third-party parsers into a security-sensitive app.
• Versioned releases with a public changelog.
• Dependencies are checked for known vulnerabilities with npm audit on every change and weekly, and kept current with Dependabot.
• Security incidents follow a written response plan: Atlassian is notified within 24 hours and affected customers as soon as possible, aiming for 72 hours.
• Vulnerability reports: security@astrospray.com, acknowledged within one business day, triaged within five.

What we do not claim

• 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. See the restore preview in the app, which lists exactly what will and won’t come back.
• Tamper-evident export signing (see the roadmap) is a hashing feature that supports an audit process. We do not claim FDA 21 CFR Part 11 compliance; compliance is a property of your validated process, not of a tool.

Uninstall

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.