01
Summary
This page describes the version in development, not a public Marketplace listing. Read the privacy policy for the legal terms.
This page describes the Estimate Gaps version in development, not the held Tallyfield Rollups for Jira Marketplace submission. The held submission still lists legacy storage and write permissions that have not been reconciled with this version. Estimate Gaps processes the Jira issue ID or key, summary, issue type, project, parent link, and Original Estimate presence only while answering the current viewer's request. It does not write Jira values, store panel results, log them, or send them outside Atlassian. The panel keeps only aggregate counts from the previous completed scan for one refresh comparison, then clears them on the next comparison, on failure, or when the panel closes. Earlier development versions left app-owned field values and Forge-hosted records. Removed field values have a 30-day cleanup target. Other Forge-hosted residuals follow Atlassian's lifecycle. The held submission described retention that could continue for up to 60 days after billing or trial ends. Development major 4 is installed on one site, and there is no production installation, so no customer production migration is currently required.
- Personal data stored
- Yes. See the records below.
- What happens after uninstall
- Each record below explains its retention. We do not make a general immediate-deletion promise.
- Where data is sent
- The version in development has no external egress. Current request processing stays between Jira and Atlassian Forge.
02
Records and retention
Current panel request data
- Purpose
- Read the issue in context and show only connected missing-estimate rows Jira returns to the person viewing it.
- Location
- Request memory in Jira and Atlassian Forge.
- Retention
- No application persistence, logging, export, or analytics retention. Refresh comparison retains only aggregate prior complete visible-gap count(s) in panel memory; no row data is retained, the completed-comparison baseline clears on the next comparison, all count memory clears on failure, and navigation or unmount discards it. Jira summaries can contain personal data and are processed transiently.
Development legacy Estimate Coverage/Rollups residuals
- Purpose
- Earlier development releases used app-owned derived-rollup fields; Forge KVS issue-to-project mappings and deletion markers; field-ownership, repair, and job state with temporary job pages; bounded aggregate analytics and recent project health; and completed hierarchy snapshots plus activation/unsupported markers. Those records supported rollup calculation, cleanup, recovery, and bounded operational status. The current panel cannot access or purge them and creates none.
- Location
- Existing development Jira app-owned fields and Forge KVS records only. No production installation currently appears, so there is no customer production migration.
- Retention
- Removed development fields follow a 30-day lifecycle. Legacy Forge-hosted residuals are subject to Atlassian's applicable Forge-hosted-storage lifecycle; the previously submitted Estimate Coverage contract described retention that could extend up to 60 days after the billing or trial period ends. The current panel creates no such records and makes no separate fixed post-uninstall retention promise.
03
Privacy
Read the privacy policy for the legal terms that apply to this product and the support channel.