Keelcroft / GitLab Issues Sync for Jira / Data deletion
Data deletion
Effective 30 October 2026 upon publication. What pause, unlink and uninstall remove — and what they retain.
App-data removal does not erase content copied into Jira or GitLab.
Issues, comments, files, attribution and links already written into either destination remain under that platform's permissions and retention. Remove or restrict those copies in the destination. The separate setup check may delete only its own disposable issue, or close it if deletion is refused.
Remove one linked pair
Use the Reconciliation Unlink action and confirm. It removes the pair record and its lookup entries, not either issue, copied comments/files, connection settings, event history or upload-recovery stages. Stale pair-recovery jobs recheck the original link and do not recreate an unlinked/replaced pair.
Unlink does not cancel work already in flight. A fresh event meeting an automatic-creation rule can link the issue again; remove its trigger label or change the rule if that is not wanted. Do not treat unlink as deletion of all metadata about that issue.
Stop all syncing without deleting
In Project settings, open GitLab Issues Sync and choose Pause sync. The app persists disabled state before attempting to delete the GitLab webhook and clears its stored webhook secret. If remote cleanup fails, the saved hook ID is retained for retry and the failure is reported; remove the stale hook manually in GitLab when necessary.
Pause retains the GitLab access token, mappings, filters, workflow/confidentiality settings, links, import/recovery records and history. Scheduled recovery skips disabled connections and consumers recheck pause, but a write already in flight may finish. Cancel import likewise stops pending creation, not an in-flight write, and does not delete issues already created.
Remove the app installation
There is no general disconnect/delete-connection control and no self-service project-only purge of every retained record. To remove the installation, pause its connections and check webhook cleanup first, then ask a Jira site administrator to uninstall the app.
Uninstall affects the entire app installation, not just one Jira project. Forge-hosted storage retention/deletion after uninstall is 0–28 days under Atlassian's platform lifecycle. This applies to app configuration, links/indexes, events, recovery/import/cursor records and encrypted secrets; it is not a promise of immediate erasure. Uninstall itself does not revoke the GitLab token or guarantee removal of an external webhook.
Record-specific retention
- Connection settings/maps and links/indexes: no automatic app TTL. Confirmed unlink removes only the selected pair/index entries. Pause retains configuration, including selection filters, workflow rules and the confidential-export boolean.
- Upload recovery stages/fences: no automatic app TTL; journals are capped at 100 stages per issue. Source identifiers, digests and timestamps persist, with known Jira attachment IDs or GitLab upload references. A GitLab reference contains an upload secret and encoded filename and can be sensitive/personal data. Pause/unlink do not purge this recovery history. Known completed processing releases its upload fence; unknown outcomes require reconciliation before clearing state.
- Latest import run: no automatic TTL; replaced by the next run. It contains up to 500 source IDs/visible keys, progress/status/timestamps and up to twenty failure key/reason entries, each reason bounded to 300 characters and potentially including rejected values. Preview titles/issue bodies are not stored in that run. Cancel is not deletion of its record.
- Recovery cursors: global last-connection and per-connection hashed scope, last/pending link identifiers and five-minute bucket have no automatic TTL. They do not contain issue bodies.
- Event journal: expires 90 days after the latest write. This TTL does not apply to upload recovery, links, configuration, import runs or cursors.
- Comment copy claims: normally removed after a pass and reclaimable after ten minutes, not guaranteed deleted by a ten-minute TTL.
- Webhook secret/access token: pause clears the webhook secret but retains the access token. Replacing a stored token is not revocation of the previous token in GitLab. Uninstall follows the Forge retention lifecycle above.
Raw comment text and file bytes are processed transiently, not stored in the event journal or upload stages. That does not erase destination copies, attribution or the sensitive GitLab upload reference. See the full privacy inventory before sharing a recovery record with support.
Things only you can remove
- External tokens: revoke the access token in the appropriate GitLab user/project settings. Do this first if exposure is suspected; uninstalling or pausing does not revoke it.
- Residual webhook: check GitLab project webhook settings after failed cleanup or uninstall, and remove the app's callback if it remains.
- Destination copies: delete or restrict copied fields, comments, files, attribution and issues using each platform's controls. Deleting a GitLab issue should not be assumed to delete its project uploads. Source comment edits/deletions are not mirrored, and confidential-export blocking does not erase earlier copies or preserve source audiences.
- A leftover setup-check issue: if the token could not delete it, the app closes it and reports that result. An appropriately authorized GitLab user can remove it separately.
Ask for a deletion in writing
Email support@keelcroft.com with your Jira Cloud hostname, project key and requested scope. The initial-response target is two business days, not a promise of immediate project-only erasure. We will clarify authorization, the available removal path and any retained recovery records. Never include tokens, upload secrets, signed URLs or unredacted issue content.