Security & data handling

Where your data lives

Everything stays inside Atlassian’s cloud. The app is built on Forge, Atlassian’s own app platform; its stored copy of your issues and the trend history live in Atlassian-hosted storage attached to your Jira site. There are no external servers, no third-party processors and no telemetry — nothing is sent outside your site. Unless a Jira admin turns on Atlassian’s app-log sharing for the site, the only thing we learn about it is what you paste into a support ticket yourself.

Because the storage is attached to your site, it follows your site’s Atlassian hosting. The app adds no storage outside Atlassian and offers no separate data-residency setting. It is eligible for Atlassian’s Runs on Atlassian program, which marks apps that keep all data and processing inside Atlassian’s infrastructure; the badge itself is granted by Atlassian when the app is listed.

What the app can access

Two read-only scopes, and nothing that can write:

• read:jira-work reads issues (keys, summaries, parent links, issue type, status category and the numeric field a gadget is configured for), runs Jira’s permission check so that each viewer sees only what they may, and reads a saved filter named in a gadget’s filter to confirm it can be used.
• read:jira-user backs the Grant access step. When the app does not yet have your permission to read Jira on your behalf, the tile shows a Grant access button instead of an error; pressing it uses this scope to ask Jira for the grant. No profile data is stored.

The app cannot create, edit or delete anything in your Jira.

If the Grant access prompt keeps returning after you approve it, the app’s earlier grant has gone stale: remove it under Connected apps at id.atlassian.com and grant access again.

Who configures, who sees what

Anyone who can edit a dashboard can add the gadget and choose its projects, field, operation and filter. Configuring a gadget grants nobody new access: the settings decide what is counted, each viewer’s own permissions decide what is shown.

The background sync reads the configured projects with the app’s own access and builds the stored copy. Every render is then filtered by the viewer’s Jira permissions, checked on each request — Browse Projects permission on each project and issue security on each issue. A project you cannot browse is counted as hidden — the tile says how many, not which — and is never shown; an issue your issue security hides is left out of your numbers. Sharing a dashboard never shares data a viewer could not already open in Jira. If Jira does not answer the permission check, the gadget hides the data rather than guess, and asks you to refresh.

The trend follows the same rule. It is one compact record of aggregate numbers per project, field and day and cannot be re-filtered per viewer, so it is checked line by line. If a multi-project gadget includes a project you cannot browse, you see lines only for the projects you can. If a project holds issues with a security level your account is not in, that project’s line is withheld, the other lines are drawn, and the panel names the missing line — without a count of the hidden issues.

A filtered gadget’s single blended line cannot be split, so it is withheld until you can browse every project it covers, and from any viewer who is outside a security level used in those projects — whatever the filter matches. See Trends.

A gadget’s JQL filter runs with the viewer’s permissions in the tile. A filter with an unpaired parenthesis or quote is refused outright, and the tile shows a filter error rather than unfiltered numbers. Filters that depend on who is asking (currentUser() and its relatives) therefore work in the tile but are refused for the live preview and for trend capture, and a saved filter must be shared with the app before the live preview and the trend can use it. See Filtering with JQL.

What is stored

Per configured project, a stored copy of what the rollup needs: issue key, project key, parent link, summary (truncated to 500 characters), issue type, status category, a flag that the issue carries a security level, and the values of the numeric fields that gadgets on your site are configured to aggregate. Alongside it: daily aggregate history — one compact record per project, field and day, aggregate numbers only, never per-issue history — and the sync’s own bookkeeping. No passwords, no tokens, no user profile data.

The gadget’s configuration (selected projects, field, operation, the JQL filter text) is stored by Jira itself as dashboard-item settings, the same way every dashboard gadget’s settings are stored. For filtered and multi-project gadgets the app also keeps its own copy of the project list and the filter text, because the daily trend capture runs in the background without a viewer present; that copy is dropped after 30 days without a view.

While the app is installed it prunes on its own. A project nobody has viewed for 30 days stops syncing and its stored copy is dropped — its history is kept, and syncing resumes on the next view; see Idle projects. Trend history keeps daily points for 90 days, weekly points to two years and monthly points after that; see Retention. When the app is uninstalled, Atlassian deletes its storage for your site as part of the Forge platform’s data lifecycle.

In your browser

The gadget remembers your view — which rows you expanded, whether the Trend panel is open, the unestimated-only mode, your scroll position — in your browser’s local storage only, for 12 hours, and forgets it when the gadget’s configuration changes. Those issue keys never leave your browser and are never sent to us.

The debug block

The debug control in the tile footer copies a block you can paste into a support ticket: build stamp, freshness, counters and configuration flags only — never issue keys, summaries or your filter text. Error messages are scrubbed of issue keys before they are included.

Support

Questions about security or data handling go through the same channel as everything else: the contact form or support@claused.io. We answer within two business days; critical breakages within 24 hours. The app is on the Atlassian Marketplace; its listing’s Privacy & Security tab carries the same answers as this page.