Jira Sync Behavior

What the integration does on each operation: the issues it creates and links, the two sync modes, how statuses travel through the mapping, and how comments are carried in each direction. For the connection model and the field mapping, see How the Jira Integration Works.

Create Ticket

Creates a Jira issue from a Qualytics anomaly with:

• Required fields: project, summary (pre-filled from the anomaly)
• Optional fields: status, priority, description, assignee
• Fixed: the issue type is always Task, and no labels are set
• Auto-included: the anomaly's details and location with links back to Qualytics, appended to the description in an info panel headed Qualytics Anomaly Linked (see Create a Jira Ticket)

Only the description carries that context. Later updates from Qualytics, the status notes and the mirrored comments, are posted as separate comments on the issue instead.

A Create Ticket flow action creates the issue automatically. Its summary and description are templates: {{anomaly_id}}, {{anomaly_type}}, {{datastore_name}}, {{container_name}}, {{check_description}} and {{anomaly_message}} are replaced for each anomaly, so every issue names what it is about.

Link Existing Ticket

Links an existing Jira issue to an anomaly:

• Creates the association between the anomaly and the Jira issue in Qualytics
• Does not modify the Jira issue: no comment is added and the issue content stays untouched

Sync Anomaly Status

When anomaly status changes in Qualytics, every two-way linked Jira issue:

• Receives a timestamped status note, opening with a panel headed Qualytics Anomaly Status: Acknowledged [2024-01-15 10:30:00 UTC]
• Is transitioned to the mapped status when Anomaly status sync is on

Read only and two-way sync

The Sync Settings group of the Jira integration settings has one switch whose title reads Two-way sync when it is on and Read only when it is off. With two-way sync, comments and status changes are posted to every linked issue. With read only, Qualytics reads the issues' status, summary and comments back and writes nothing to Jira. The integration setting is the master: while it is two-way, each ticket card on an anomaly has its own Two-way / Read only button that narrows that one issue to read only. While the integration is read only, the card hides the button, because no issue can be written to.

Anomaly status sync

The Sync Settings group also holds a box with its own switch and a Mapping row that opens the Status Mapping dialog. Off, the box reads Anomaly status not synced. On, it reads Anomaly status sync with a Two-way or Read only badge that follows the switch above. Status sync is off by default.

The dialog has one row per anomaly status (Active, Acknowledged, Resolved, Duplicate, Invalid, Discarded), each with a combobox of your Jira projects' statuses grouped by category (Open, In progress, Done). Every status carries chips naming the projects whose workflow has it, and a name that appears under two categories is listed once per category. A status name that is not listed can be typed. Clearing a row leaves it unchanged (the field then reads Leave unchanged): that anomaly status moves no issue, and no issue status pulls the anomaly into it. Reset on the left reloads the statuses and refills the rows with the defaults, Cancel discards the edits, and Apply saves them. Apply stays disabled while every row is unchanged, so at least one row must be mapped.

When the switch is turned on the rows are filled in with To Do for Active, In Progress for Acknowledged and Done for the four archived statuses, as long as your projects have statuses with those names. Otherwise the first status of the matching category (Open, In progress or Done) is used.

With the switch on:

• Anomaly to issue (two-way issues only): when an anomaly's status changes, each issue is transitioned to the mapped status. If the issue's project workflow lacks that status, the issue moves to a status in the same category (open, in progress or done) instead. Nothing moves when the issue is already there. The status note comment is posted as before.
• Issue to anomaly: when an issue changes status, Qualytics looks at every issue linked to the anomaly, two-way and read only alike. The anomaly moves only when all of them sit at statuses mapped to the same anomaly status. One issue still open keeps the anomaly where it is until it closes too. When several anomaly statuses map to the same issue status, the first in this order wins: Active, Acknowledged, Resolved, Invalid, Duplicate, Discarded. Done therefore resolves the anomaly rather than marking it Invalid, Duplicate or Discarded. An archived anomaly is never moved by an issue, and an issue status that is not in the mapping never moves anything.

Read only issues are never moved by Qualytics, but their status counts when deciding whether the linked issues agree. An anomaly changed by its issues behaves like one changed by a person: its two-way issues follow, flows on Anomaly Status Change run, and the timeline records the change.

Sync Comments

When comments are added to anomalies in Qualytics:

• The comment text is synced to linked tickets as Jira comments
• The comment opens with a Qualytics | Comment from <author> panel. When the author's email matches a Jira account, that account is mentioned

The pushed copy follows its Qualytics comment for life: editing the comment in Qualytics rewrites the copy on the issue, and deleting it removes the copy. Both follow the same switches as the original push, so nothing is rewritten or removed on an issue that has since been set to read only.

Comments from Jira

Comments written on a linked issue are mirrored onto the anomaly's timeline, and edits and deletions follow. Each shows which issue it came from.

• When the author's email address is visible to the integration's account and matches a Qualytics user, the comment is attributed to that user
• Otherwise the comment is shown under the author's Jira display name, with the ticket it came from beside the timestamp. Jira Cloud hides email addresses by default, so this is the common case for anyone other than the integration's own account
• Comments Qualytics wrote itself (mirrored comments, status notes and the link note) are recognized by their heading and are not imported back
• Deleting the issue's copy of a comment that was written in Qualytics does not delete the comment in Qualytics: the author's words stay, and only the syncing between the two stops

The comment arrives as plain text, so a mention shows up as a raw text code rather than as the formatted name you saw when typing it, and the mentioned user is notified in Qualytics only. A reply arrives as its own Jira comment with no indication of which comment it answers, because Jira comments are a flat list. The anomaly's Timeline in Qualytics keeps the full thread with its structure.

See Also