Open Settings → Marketplace apps → UndoTrail. Anyone who can reach the page can read it. Only Jira administrators can change anything, and the page says so when you cannot. Each section saves on its own.
The first time you open any part of UndoTrail, Jira asks you to Allow access (the app reads Jira as you, with your permissions). Everyone on the site sees the same screen once, the first time they open the app; see Getting started.
The page has ten sections, in this order: Subscription, Deleted work items, Tracking, Time format, Permissions, Backfill, Erase captured tracking data, Scheduled reports, Verify a signed export, and Data and privacy.
1. Subscription
Read-only information about the licence, plus the access-code control.
| Field | Meaning |
|---|---|
| Status | Active or Not active |
| Source | Atlassian Marketplace subscription, Free access code, Unlisted installation (development or private site), or No active subscription |
| Trial | Shown during an evaluation, with the end date |
There is one plan and every feature is included. Billing is handled by Atlassian under Manage apps.
Free access codes
Access codes let reviewers and pilot teams use the full app without a subscription.
- A code looks like
WIH1.…and is issued to one named organisation, for one site (or any site), with a fixed expiry date. - Paste it into Access code and press Redeem. The app verifies the signature, the site and the expiry before accepting it.
- Once redeemed, the page shows who it was issued to, which site it covers and the date it runs until.
- Remove deletes the grant. The Marketplace subscription then decides what is available again.
- Only Jira administrators can redeem or remove a code.
- Refusals are explicit: That doesn’t look like an access code, That access code is not valid, This code was issued for (site), not (your site), This code expired on …, or Access codes are not set up for this app installation.
A code is not a purchase and creates no ongoing entitlement. When it expires, the app returns to whatever the Marketplace licence says.
2. Deleted work items
| Setting | Default | Range | Notes |
|---|---|---|---|
| Keep deleted work items for (days) | 90 | 1 to 365 | Applies to items deleted from then on. Snapshots already stored keep the expiry they were given |
Retention is an expiry on the stored snapshot. When it passes, the snapshot is removed and the item can no longer be restored. The same control appears at the top of the Deleted items tab for admins. See Deleted items.
3. Tracking
| Setting | Default | Effect |
|---|---|---|
| Keep comment history | On | Stores each version of a comment as it is added, edited or deleted |
| Keep viewer history | On | Records who opened a work item and when. No page content is stored |
| Exclude these projects | Empty | Comma-separated project keys, for example HR, LEGAL. Neither record is kept for those projects |
Deleted-item snapshots are not affected by these settings. See Tracking for the privacy points.
4. Time format
How durations are shown when a time field changes, for example Original Estimate or Time Spent, and in the Time in value report.
| Setting | Default | Options |
|---|---|---|
| Style | Jira | Jira (1w 2d 3h), Decimal hours (11.5h), Minutes (690) |
| Hours per working day | 8 | 1 to 24 |
| Days per working week | 5 | 1 to 7 |
Match these to your Jira time-tracking settings so the numbers agree with Jira’s own.
5. Permissions
Choose who can use each part of the app: everyone, Jira admins only, or chosen Jira groups. Jira administrators always have access, whatever is set here.
| Feature | What the setting controls |
|---|---|
| History reports | The Changes and Reports tabs, Get change history in Jira’s issue search, saved views, the dashboard gadgets, the Changed by group filter, scheduled reports and the Rovo agent’s change-history answers. Someone without it sees a note saying so, and can still use a work item’s own History+ tab |
| Export (CSV, XLSX, PDF) | Every download: the Changes tab, a work item’s history, the Reports tab (CSV, Excel, PDF and the chart’s SVG and PNG), Deleted items, the Security scanner and the revert dry run, plus signed exports and scheduled reports |
| Revert and bulk revert | Selecting changes and reverting them, on the Changes tab and on a work item’s history |
| Deleted work items | The Deleted items tab, the restore preview and restoring, and the Rovo agent’s deleted-items answers |
| Security scanner | The Security scanner tab and the Rovo agent’s scan. Starts as Jira admins only |
| Viewer history | The Viewed by tab on a work item |
Each is set with Who can use … to one of three levels:
- Everyone: anyone who can open the app. This is where every feature starts, except the scanner.
- Jira admins only: people with Jira’s Administer Jira permission, and nobody else.
- Only these groups: members of the Jira groups you choose. Choosing this loads your Jira groups; a group already saved stays in the list even if it cannot be loaded.
Press Save permissions to apply.
The Security scanner starts as Jira admins only. It gathers every secret and piece of personal data a person can see into one list, in one click, so it stays with the admins until you decide otherwise. To hand it to a security team, set it to Only these groups and choose their group.
Three points worth being precise about:
- Jira’s own permissions always apply underneath. Nobody sees history for a work item they could not open in Jira, whatever these settings say.
- Wherever the app’s backend serves the data (deleted work items, viewer history, saved views, the group lookup, signing an export, scheduled reports and the Rovo agent’s actions), the check runs on the server on every request, and someone outside the groups gets Your Jira administrator hasn’t given you access to …. Reports, exports, revert and the scanner otherwise run in your browser against Jira’s own API under your own permissions, and there the setting removes the feature from the app’s interface. The boundary around the Jira data itself is Jira’s own permission scheme.
- The Rovo agent follows these settings too: each action checks the matching feature before it answers.
6. Backfill
A work item is snapshotted whenever it is created or changed. Items untouched since the app was installed have no snapshot, so a later deletion would only be captured partially.
- Snapshot every work item starts a one-off job that reads every work item on the site, page by page, in the background. It reads as the app, so it covers 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. A partial capture is shown only to Jira administrators.
- The status line reports Backfill running, Backfill finished or Backfill stopped, with the number scanned and the number snapshotted, and refreshes every two seconds while it runs. If a backfill can’t start or stops part way, the line says why, and you can press the button again.
- Existing snapshots are never overwritten, so a fresher snapshot from a real change always wins.
- A backfill snapshot holds every field a restore uses, custom fields included, the same as a snapshot taken when a work item changes. It reads 50 work items at a time with a short pause between pages, and waits whenever Jira asks it to slow down.
- Only Jira administrators can start one, and only one can run at a time.
- You can leave the page. Come back later to see the result.
Run it once after installing, and again after a large import or migration.
7. Erase captured tracking data
Removes comment versions and view records that have already been captured, for the whole site or one project. Use it to answer a data-protection request without uninstalling the app.
| Control | Options |
|---|---|
| What to erase | Comment history and view records, Comment history only, or View records only |
| Project key (blank = all projects) | One project key, or empty for every project |
Press Erase…, read the question the app asks, then press Yes, erase. The app says how many stored records it removed. Only Jira administrators can erase, and it cannot be undone. New activity is still captured unless tracking is also switched off above. See Tracking.
8. Scheduled reports
Reports that run every day, week or month and are delivered to a Jira work item as an attachment plus a comment. The section lists each schedule with its last run, and has Run now and Delete buttons. See Scheduled reports.
9. Verify a signed export
Choose a file under Exported file to check whether it is byte-for-byte the export that was signed. The file stays in your browser; only its SHA-256 fingerprint is looked up. See Signed exports.
10. Data and privacy
A plain summary of what the app stores in Forge storage on your site: work item snapshots, comment versions and view records (both on by default), saved views, scheduled reports, signed-export records, each person’s guide and tour progress, and these settings. It also states what is not stored: change history itself, which is read live from Jira in the browser of the person looking at it. The same list, with how long each is kept, is in Permissions and security.
Limitations
- Settings are site-wide. There is no per-project retention, time format or permission set.
- Erasing tracking data works for one project or the whole site, not for one person.
- Retention cannot exceed 365 days.
- Group permissions apply to app features, not to individual projects or fields.
- The backfill has no cancel button. Starting a new one is blocked while one is running. A run that has reported no progress for 15 minutes counts as stalled, and can be started again.