CloneGuard for Jira

1. What CloneGuard does

CloneGuard creates same-site Jira copies from a fixed, reviewed contract. It helps administrators and delivery teams see schema, permission, field, comment-visibility, and hierarchy differences before a clone starts, stop safely if the contract changes, and retain source-to-target evidence afterward.

2. Where to open it

• Open a Jira work item and choose the CloneGuard issue action to start with that item.
• Open CloneGuard from Jira’s Apps area to review active and completed jobs.
• Jira administrators can open CloneGuard settings to read permission, retention, and data-handling policy.

The Issue Navigator multi-selection action is not part of this release because Jira does not currently provide reliable exact multi-selection context to that preview module.

3. Safe clone workflow

1. Select one Jira work item, its supported hierarchy, or explicit JQL and choose a destination project on the same Jira site.
2. Choose content such as descriptions, comments, attachments, and internal links.
3. Run preflight. CloneGuard reads the source, destination schema, permissions, users, options, comment visibility, and hierarchy without creating targets.
4. Resolve every blocker by mapping or explicitly skipping it.
5. Review and approve the fixed contract. The one-use receipt binds the request, decisions, initiating account, and expiry.
6. Start the job. CloneGuard revalidates before writes, at batch boundaries, and before each item. Drift pauses the job for a revised review.
7. Review results. A target becomes Verified only after CloneGuard rereads the approved fields and selected artifacts from Jira.
8. Prepare and download the Evidence Package. The browser recomputes its integrity digest before download.

4. Supported content and limits

CloneGuard supports Jira Cloud sites and same-site destinations. A contract may select up to 500 items. Current budgets are up to 500 comments and 100 attachments per item, 5,000 comments and 200 attachments per contract, 25 MB per attachment, and 100 MB of attachment bytes per contract. Operations also remain subject to Jira and Forge quotas and permissions.

CloneGuard does not preserve original authorship or timestamps, copy worklogs or third-party app data, bypass Jira permissions, perform arbitrary workflow transitions, modify source work items, delete Jira items, or roll back targets already created. Restricted comments require compatible destination visibility. Unsupported or incompatible data must be explicitly mapped or skipped before approval.

5. Fail-safe behavior

• A changed source, schema, permission set, or approved request pauses execution for review.
• A lost or uncertain Jira write response is not retried by guessing. CloneGuard stops and requires reconciliation.
• Safe stop finishes only the current item. Completed source-to-target mappings remain fixed, and only unfinished items are eligible after reapproval.
• Reverify rereads existing targets and does not create new Jira items.

6. Permissions and licensing

Every Jira content operation runs as the user who initiated the job, and Jira enforces that user’s current permissions. CloneGuard checks access during preflight and again during execution. An active Marketplace license or evaluation is required for write operations; an inactive license cannot start or change clone work.

7. Data, retention, and Evidence Package

CloneGuard runs on Atlassian Forge with no declared remote backend, external network egress, or analytics SDK. Installation-scoped Forge storage holds minimized identifiers, mappings, fingerprints, decisions, statuses, timestamps, artifact results, safe error codes, and templates for up to 365 days. Jira description bodies, comment bodies, attachment bytes, passwords, API tokens, and secrets are not stored in job history or application logs.

The Evidence Package contains selected source results, mappings, approval receipt, contract, manifest, events, and integrity digest. It may contain Jira issue identifiers and Atlassian account identifiers, so handle downloaded JSON according to your organization’s access and retention policy.

8. Support

When requesting support, identify CloneGuard, the app version, Jira site, approximate time, safe error code or request ID, and affected item identifiers. Do not include passwords, API tokens, private descriptions, comments, or attachment contents in the first message.

Report security concerns privately through the security policy.