Keelcroft / Cross-Site Issue Sync for Jira

Cross-Site Issue Sync for Jira

Jira to Jira sync between two Jira Cloud sites, where only your site installs anything.in review

What it does

A Jira project administrator connects one project on their site to one project on a partner’s Jira Cloud site — a client, a contractor, a vendor, or another business unit — chooses which fields travel in which direction, and links issues by key. A change on either site is then carried to the other, verified, and recorded.

• Summary, status and labels, in either or both directions. Description as plain text, if you switch it on.
• Optional auto-create: new issues on the partner site appear here, new issues here appear on the partner site, or both. Only issues created after sync is turned on are copied, so an existing backlog is never duplicated by surprise.
• A reconciliation view listing every linked pair with its agreement state, how long ago the pair was last proven identical, and a replay button for anything out of agreement.
• A setup check that signs in to the partner site, creates a disposable issue in the partner project, reads it back, verifies it and deletes it again.

Only one site pays and installs

The partner site installs nothing and buys nothing. Your site reaches the partner project with the email address and API token of one user on the partner site — ideally a dedicated integration account — which the partner’s administrator can create and revoke at any time.

How changes are noticed

• Changes on your site arrive through Jira’s own issue events, immediately.
• Changes on the partner site arrive within seconds when the partner user is a Jira administrator there: the app registers a signed webhook limited to the partner project, and verifies its signature on every delivery. Otherwise, and as a safety net in every case, the app asks the partner project every five minutes which issues changed in the last hour.

Both paths identify a change by the partner issue id and its update time, so a change announced by the webhook and found again by the check is synced exactly once.

How verification works

• It reads both sites and works out which fields actually changed since the pair last agreed.
• It writes only those fields.
• It then reads the site it just wrote to again, and compares the stored values with what it asked for.
• The outcome, including any value the site refused to store, is recorded against the pair and shown in the reconciliation view.

What it deliberately will not do

• It never deletes an issue on either site. If one side of a pair disappears, the pair is marked failed and the surviving issue is left alone. The only issue this app ever removes is the disposable one its own setup check created.
• It never overwrites an edit silently. Edits on both sites are applied in both directions when they touch different fields. A real collision is resolved by the policy you chose and the losing edit is always reported. If both sites changed at the same instant, the pair is held as a conflict.
• It never writes a status it was not told about. An unmapped status is reported instead of being forced onto the other site.
• It does not relay your data through our servers. The app runs on Atlassian Forge and calls the partner site directly. There is no vendor-hosted middleman.

Current limits

• Jira Cloud on both sides. The partner must be a site on atlassian.net; Jira Data Center is not supported.
• Assignees are not synced. User accounts belong to one site.
• Description is plain text and off by default. Formatting, tables, mentions and images are not copied.
• Comments, attachments, sprints, custom fields and issue links are not synced in this version.
• A label containing a space cannot exist in Jira, so such a value is reported rather than rewritten.
• The partner workflow decides. A status is applied through a workflow transition; if the partner workflow has no transition to the mapped status, the pair reports it.
• API tokens expire. When the partner token expires, sync stops and the pairs report the authentication failure until a new token is stored.
• One project to one partner project.
• Runs on Atlassian does not apply. Moving data between two sites requires egress, which makes that badge unavailable to every cross-site sync app by definition.

Support

Email support@keelcroft.com. Security reports: same address, subject line “Security”.

Jira and Atlassian are trademarks of Atlassian Pty Ltd. Keelcroft is an independent publisher and is not affiliated with, endorsed by, or sponsored by Atlassian.