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

Inizia da backend/plugins/jira/models/issue_changelog.go, quindi segui il percorso di upsert dell’estrattore Jira per JiraIssueChangelogItems. Riproduci i due elementi con lo stesso campo e analizza le implicazioni della modifica dello schema; il lavoro è completato quando entrambi gli elementi persistono senza collisioni dopo una nuova estrazione, con una copertura di regressione per il caso segnalato.

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.