Privacy Policy
Portal Attachments for Jira Service Management adds a Files panel to a Jira Service Management customer portal request. Jira Service Management's own portal shows a customer only the files a public comment carried; a file attached on the Jira create screen, or by an agent working the request, is carried by no comment and is therefore invisible to the customer looking at their own request. This app lists those files and lets the customer download them, under a visibility policy an administrator sets.
The app runs entirely on Atlassian's own infrastructure using Atlassian Forge. Its manifest declares no permissions.external block and no remote hostname, and the only module that touches @forge/api calls requestJira, which is Atlassian-internal. Nothing this app reads or writes leaves Atlassian's infrastructure, and the vendor operates no server your data passes through.
The app's configuration is held in Forge storage, hosted by Atlassian inside your Atlassian cloud environment and scoped to your installation of this app.
The app stores a policy, never a decision:
The site-wide policy: two true/false switches — whether reporter uploads are listed, and
whether agent uploads are listed — and the timestamp of the last change.
The same two switches for each project that has an override, plus an index of which
project ids have one.
That is the whole of it. Nothing the app stores names an attachment, a request, a project name, a comment or a person. A project id is an opaque numeric identifier Atlassian assigns; it is configuration, not personal information about anybody.
The app stores no personal data. It does not store account IDs, email addresses, display names, avatars, request content, comment text, filenames, file bytes, credentials or tokens. It performs no analytics, telemetry or tracking of any kind, and it writes to no sink outside Forge.
Every time the panel renders, the app reads from Jira — as the app, not as the person viewing — and then throws the result away:
Read | Why |
|---|---|
The request's attachment list, reporter and project | The panel cannot list a file it cannot read, and the project is what a per-project override is keyed on |
The request's comments, with each comment's public/internal flag | Whether a public or an internal comment carried a file is the fact the whole visibility decision rests on |
The request's participants | Participants are what widen the default audience beyond the reporter |
The bytes of one file, when somebody clicks Download | No Jira route hands an attachment to a portal customer directly, so the bytes are proxied through the app's own resolver |
None of it is persisted. The decision is recomputed from these facts on every read, and the download route recomputes it again before a single byte is fetched.
A file carried by an internal comment is never listed and never downloadable. That is not a setting, it has no switch, and asking the download route for such a file directly is refused.
Scope | What it is for |
|---|---|
| Read the request's attachment list, its reporter and its project, and fetch the bytes of a file the policy has already admitted |
| Read the request's comments — including whether each is public or internal — and its participants |
| Store the visibility policy: two switches site-wide, and the same two per project that has an override |
The app declares no write scope of any kind. It never creates, edits, deletes, renames or re-orders an attachment, a comment, a request or a project.
The app's configuration page lives under Apps in Jira administration and is reachable only by a Jira administrator. It holds the site-wide policy, a per-project override table, and a live count of what the panel is currently exposing across the site, so the effect of a change is readable before and after it is made.
The policy persists until an administrator changes it. There is nothing else to retain: no per-attachment record is ever written, so there is no per-attachment record to delete.
Uninstalling the app removes all of its stored data, because Forge storage is scoped to the installation. No Jira data changes meaning when the app is removed — every attachment, comment and request is exactly as Jira left it.
Forge storage follows your Atlassian cloud instance's data residency. The vendor cannot choose or change where it is held.
Questions about this policy, a security report, or a request to remove data: support@maxpetrov.pp.ua
Last updated: 18 September 2026.