Security and permissions

Issue History Export reads Jira history using the current user’s permissions. It does not change work items.

Where the app runs

The app uses Atlassian Forge for its Jira integration and saved presets. Files are generated in the user’s browser. The app has no configured external egress service, analytics or advertising integration.

Jira content passes through Forge and the browser while a report is prepared. It is not copied to a separate provider-operated database. The public website and voluntary support correspondence have separate data flows described in Website privacy.

Permissions and why they are needed

The production manifest requests these Forge scopes:

These scopes grant no permission to edit Jira work items.

Access to Jira data

Jira API calls run as the signed-in user on fixed, validated routes. The backend does not accept arbitrary URLs or a client-supplied identity. It validates selection and preset inputs and checks the trusted license state before protected operations.

Before each download, the app checks access again and refreshes work item keys and summaries. Unavailable work items are removed from exported rows and item details; only an excluded count and reason remain. Permissions can still change after this check. The app cannot revoke a file someone already downloaded.

Stored settings

Forge storage isolates installations. Within an installation, presets are stored under a key derived from the authenticated account ID. The client cannot choose another owner. Presets include names, selections, query text, dates, time zones and filters; query and filter text can contain sensitive information.

The app also stores owner account IDs and retention dates for Atlassian privacy reporting. A scheduled Forge function reports those details to Atlassian and removes presets when Atlassian requests erasure. It runs independently of the user session and license.

History rows and generated files are not stored in app storage. Users can delete their own presets, including after license expiry. See retention and deletion.

Data residency

Saved presets, including their names, queries, filters and ownership metadata, are stored in Forge hosted storage. This data follows the linked Jira app’s supported data residency location.

Downloaded files and browser memory, voluntary support correspondence, Atlassian platform logs and account privacy reporting are outside this data residency scope. Forge may process requests outside the location used for stored presets. See Atlassian’s Forge data residency documentation.

Export safeguards

XLSX user values are written as text, never executable formulas. CSV formula-like values receive a protective leading apostrophe; technical state columns preserve the distinction between empty, null and missing values. Oversized or unsupported Excel cell values produce an error instead of silent truncation.

Selection, request, byte and row limits bound each report. Retries for temporary Jira failures are bounded. Interrupted or ambiguous reads are reported as partial rather than complete.

Diagnostics and support

The application does not intentionally log work item content, query text, account names or export rows. User-visible diagnostics describe the failure stage and request counts. Atlassian supplies platform logs and operational metadata under its support controls.

Mikhail Eshchenko uses account controls for operational access. This page describes the app’s safeguards; it is not a certification or an independent penetration-test report. Report security concerns through private support.