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 outside Atlassian. There is no Keelapps server involved in running this app: it 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, MIME type, upload date, uploader account id, issue key and id, issue type, project key | Jira REST API | Forge storage (KVS), inside your Atlassian tenant | Yes, in inventory records — see below |
| Attachment file content | Jira REST API | Your browser's memory, then your download folder | No. Never stored by the app, in Forge or anywhere else |
| Account ids — of whoever runs an inventory, deletes an attachment or changes a setting | Forge invocation context | Inventory and audit records | Yes — see below |
| Display names | Jira REST API, looked up as the person viewing a screen | That screen | No. Never stored |
| The files a deletion preview covers, as Jira describes them | Jira REST API | Forge storage | At most six hours |
| Site settings | The admin page | Forge storage | Yes, until changed |
Where it is stored
Forge storage (KVS), 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:
- Inventory records — the attachment list produced when someone runs a project inventory. Metadata only, never file content; uploaders are stored as account ids. The ten most recent inventories per project are kept; an older one is deleted automatically when an eleventh is created, and the person who ran one, or a project or Jira administrator, can delete it from the project page at any time. Inventories taken with versions before 2.3.0 also hold uploaders' display names, until they are replaced or deleted.
- Deletion previews — the files someone chose to delete, as Jira described them (name, size, issue), held so the deletion removes exactly what was previewed. Removed when the dialog is closed, and otherwise expire within six hours.
- Audit records — one per attachment deleted through the app (who, what, when, the reason they typed, and Jira's answer) and one per settings change. Kept for 400 days, then removed automatically, a batch at a time, whenever that trail is opened or an inventory is started in the project — so a trail nobody opens can hold older records until then. Nothing in the app removes them sooner, and no screen offers to.
- Settings — the deletion switch, archive limits, 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.
- Operational logs. The app writes log lines to Atlassian's Forge logging: which operation ran, status and error codes, counts and timings. No file contents, file names, issue keys or JQL. Keelapps can read these logs while your site's Logs access setting for the app is on, which is the default; a site admin can download them, or turn Keelapps's access off, in Atlassian Administration → Connected apps → Satchel → Logs access.
- No attachment content, anywhere, at any time. This is architectural, not 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.yml contains no permissions.external
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, which is checked by an automated test on every build
(test/writeSurface.test.js).
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 (including checking which of a project's issues you can see), read attachment metadata and content, and check whether you are an administrator. This is how the app finds and downloads files, and how it decides what to show you. -
read:jira-user— look up display names for account ids, as you, when a screen shows one: who uploaded a file in an inventory, who is named in an audit record. Names are not stored. -
write:jira-work— Satchel holds this only because deleting an attachment needs it, and the only write call in its code isDELETE /rest/api/3/attachment/{id}. Atlassian's consent text for this classic scope mentions creating and editing issues, posting comments, creating worklogs and deleting issues. Satchel does none of those things, and never uploads anything. It is the only classic Jira scope that includes deleting an attachment; the granulardelete:attachment:jirascope would say exactly that, and it is still in beta. Deletion also ships switched off, and when an administrator switches it on it is limited to Jira administrators unless they widen it. -
storage:app— the Forge storage described above.
Permissions are yours, not the app's
Every attachment read, every search, every permission check and every deletion
runs as you, through Forge's asUser() API, so Jira's
own permissions — project permissions and issue security — decide what you get. If
you cannot open a file in Jira, Satchel cannot hand it to you. (Jira does not
restrict an attachment added in a restricted comment: anyone who can view the
issue can open it, in Jira and in Satchel.)
The one exception is the project inventory, which runs as the app because a queued job has no signed-in user, so it can reach issues some project members cannot see. Every time its rows are read — the list, the reports and the numbers — they are filtered to the issues the person reading can see in Jira, and if Jira cannot be asked in time, nothing is shown.
Deleting from a project page covers that project only: Satchel checks every file with Jira, as you, before the preview, and deletes only files it confirmed are on those issues in that project.
Deletion is irreversible
Jira has no recycle bin for attachments (JRACLOUD-81027). A deleted file comes back only from a copy you took beforehand; Atlassian does not undo customer deletions from its own backups. Satchel lists the files it will delete, requires a typed confirmation, and records every deletion — but it cannot undo one.
Removing your data
Uninstalling the app ends its access to its Forge storage. Atlassian keeps an uninstalled app's storage for 28 days — a reinstall can be relinked to it if that is requested within 21 days — and then deletes it. Nothing is held anywhere else.
To remove an inventory without uninstalling, delete it from the project page. Audit records cannot be deleted from the app's screens — an audit trail its users can erase is not an audit trail; they are removed automatically after 400 days. Keelapps has no access to your site's data and cannot remove records for you.
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.