keelapps/Satchel for Jira/Privacy policy
Privacy policy — Satchel for Jira
The short version
Satchel for Jira (“Satchel”, “the app”) is published by Keelapps. Satchel does not send your data anywhere. There is no Keelapps server involved in running this app, because the app runs entirely on Atlassian's infrastructure and its manifest declares no permission to contact any external host. Attachment files never pass through us: when you download an archive, the bytes travel from Jira to your own browser, where the zip is assembled, and then to your disk.
What the app processes
| Data | Where it comes from | Where it goes | Retained? |
|---|---|---|---|
| Attachment metadata — filename, byte size, media type, upload date, uploader account id and display name, issue key, issue type, project key | the Jira REST API | Forge storage, inside your Atlassian tenant | Yes, in scan records — see below |
| Attachment file content | the Jira REST API | your browser's memory, then your download folder | No. Never stored by the app, in Forge or anywhere else |
| Your Atlassian account id and display name | the Forge invocation context | audit records, when you delete something or change a setting | Yes, until pruned |
| Site settings | the admin page | Forge storage | Yes, until changed |
Where it is stored
Forge storage, which is Atlassian infrastructure inside your own tenant's data boundary. Not a Keelapps database — there isn't one. Data residency follows whatever your Atlassian site is configured for; the app has no separate region and cannot move data out of yours.
Stored records:
- Scan records — an attachment inventory produced when someone runs a project scan. Metadata only, never file content. The ten most recent scans per project are kept; older ones are deleted automatically when an eleventh is created.
- Audit records — one per attachment deleted through the app, and one per settings change: who, what, when, and the reason they typed. Capped at 500 per project, oldest dropped first.
- Settings — the deletion switch, archive limits, and the transfer mode.
Where it is not stored
- No analytics service. The app sends no telemetry, no usage events and no error reports to any third party.
- No external logging. Application log output goes to Atlassian's own Forge logs, which are visible to your site administrators and to Atlassian, and to nobody else.
- No attachment content, anywhere, at any time. This is architectural rather than a policy promise: the backend reads attachment bytes only when relaying a slice to your browser mid-download, and that slice is held in function memory for the duration of one request.
No external transmission
The app's manifest contains no external permissions block. In Forge, an app cannot make a network request to a host it has not declared, and any declaration is shown to an administrator at install time. There is no such declaration here, and an automated test on every build checks that it stays that way.
This is also what makes the app eligible for Atlassian's Runs on Atlassian badge, which Atlassian applies after verifying the same thing independently.
Permissions, and what each is for
At install you are asked to grant four scopes:
- Read Jira work — read issues, run JQL searches, read attachment metadata and attachment content. This is how the app finds and downloads files.
- Read Jira user — turn an uploader's account id into a display name, so a storage report names a person rather than an identifier.
- Write Jira work — used for exactly one API call: deleting an attachment. Atlassian's consent text for this scope mentions creating and editing issues, posting comments, creating worklogs and deleting issues. Satchel does none of those things. It is the narrowest scope Atlassian currently offers that includes deleting an attachment; the granular scope that would say exactly that is still in Beta. Deletion also ships switched off and is administrator-only when enabled.
- App storage — the Forge storage described above.
Permissions are yours, not the app's
Every attachment read and every deletion runs as you, using your own Atlassian identity. If you cannot open a file in Jira, Satchel cannot hand it to you — including attachments hidden by issue security levels or added inside restricted comments, which Jira withholds at the API level.
The one exception is the background project scan, which runs as the app because a queued job has no signed-in user. Its output is attachment metadata for a governance report, and anything offered for download is re-fetched as you.
Deletion is irreversible
Jira has no recycle bin for attachments. An attachment deleted through Satchel is gone from Jira, and the only recovery is an Atlassian support restore of the entire site. The app requires a dry-run preview and a typed confirmation, and records every deletion — but it cannot undo one.
Removing your data
Uninstalling the app deletes its Forge storage, including every scan and audit record, according to Atlassian's own retention schedule for uninstalled apps. There is nothing held anywhere else to request the deletion of.
To clear records without uninstalling, delete a scan from the project page. To clear the audit trail, contact support — it is deliberately not deletable from the interface, because an audit trail a user can erase is not an audit trail.
Sub-processors
None. The app has no infrastructure of its own.
Children
The app is not directed at children and processes no data about them beyond whatever a Jira administrator has put into their own instance.
Changes
Material changes to this policy will be published with a new version of the app and reflected in the Marketplace listing. The effective date above moves with any change.
Contact
support@keelapps.atlassian.net — for questions about this policy, and for data access, correction or deletion requests.