JiraIssueChangelogItems primary key collision when Jira reports multiple items with the same field in one changelog entry

[LuisFerFloresM]

Summary

JiraIssueChangelogItems has a composite primary key of (ConnectionId, ChangelogId, Field). When Jira returns multiple items with the same Field value within a single changelog history entry, the second item silently overwrites the first on upsert.

Steps to reproduce

1. Have a Jira issue where a single-value field (e.g. fixVersions) is changed from value A to value B in one action
2. Jira's API represents this as two changelog items in the same history entry:
   • Fix Version: null → B (add)
   • Fix Version: A → null (remove)
3. Both items share the same ChangelogId and Field = "Fix Version"
4. Run the Jira extractor — only one item survives in _tool_jira_issue_changelog_items

Expected behavior

Both changelog items should be stored — the add and the remove.

Actual behavior

The second item overwrites the first because they collide on the primary key (ConnectionId, ChangelogId, Field).

Impact

Any downstream query that relies on changelog items to detect whether a specific value was ever added to a field (e.g. filtering issues by historical fixVersions) will produce incorrect results. This affects fixVersions, labels, components, affectedVersions, and any other field where Jira emits multiple items with the same field name in one history entry.

Suggested fix

Add a disambiguating column to the primary key — for example an item ordinal/index within the changelog entry. The model is in backend/plugins/jira/models/issue_changelog.go:

type JiraIssueChangelogItems struct {
    ConnectionId uint64 `gorm:"primaryKey"`
    ChangelogId  uint64 `gorm:"primaryKey"`
    Field        string `gorm:"primaryKey"`
    // no item-level disambiguator
}

Existing data would need re-extraction after the schema change, since collided rows already lost one of the two items.

Version

Verified on v1.0.3-beta10 and confirmed the PK is unchanged on main as of 2026-08-17.

[mfrancisc]

Thanks for the clear write-up. Indeed Jira’s changelog items array has no item id, and fields like Fix Version / Component / labels often appear twice in one history entry (add + remove). Since the Jira plugin upserts on connection_id, changelog_id, field, the second item overwrites the first one.

Proposed fix: #9062 - add item_index to the tool-layer PK and to the domain changelog id. Index is a per-field ordinal derived from the item values, not array order.

To test this fix, run a Jira pipeline once. The migration resets extract/convert state so existing _raw_* changelogs are re-extracted; A re-collect from Jira is not required, unless that raw data is gone. Collided rows that were already dropped cannot be repaired in place without that re-extract.