Skip to content

Incident Management v2: Jira Service Management connector #53

Description

@Aidaho12

Parent epic: #45

Architectural direction

This issue follows the approved Incident Management v2 separation:

Alert -> AlertGroup -> Incident
  • AlertGroup owns technical deduplication, source status, routing, notifications and escalation.
  • Incident owns operational lifecycle, priority, commander, responders, stakeholders, affected services, root cause, resolution and ITSM references.
  • Current technical behavior moves from /api/incidents to /api/alert-groups.
  • /api/incidents is replaced directly and exposes only first-class Incidents.
  • No /api/managed-incidents, compatibility alias or intermediate API is introduced.
  • Manual AlertGroup creation explicitly creates an AlertGroup and initial child Alert.
  • Manual Incident creation creates only a first-class Incident.

Architecture document: docs/architecture/incident-management-v2.md

Goal

Implement Jira Service Management as the first provider on the generic Incident ITSM framework.

Scope

  • Create JSM issues from first-class Incidents.
  • Configure project, issue type, priority, status and selected field mappings.
  • Store JSM key, ID and URL as Incident external references.
  • Update selected Incident fields and status according to configured ownership.
  • Include linked AlertGroups and technical context in the JSM description or structured fields.
  • Process authenticated JSM webhooks with replay and loop protection.
  • Expose retries, mapping errors and conflict state.
  • Document administrator setup and operator behavior.

Acceptance criteria

  • Issue creation is idempotent and never creates duplicate JSM tickets for the same requested operation.
  • JSM synchronization reads and writes Incident records, not AlertGroup records.
  • Credential and webhook verification failures are safe and observable.
  • Mapping errors do not lose local Incident state.
  • Linked AlertGroups remain visible as technical evidence after JSM synchronization.
  • Source-of-truth and conflict behavior follow the generic framework configuration.

Dependencies

Metadata

Metadata

Assignees

No one assigned

    Labels

    incident-management-v2Incident Management v2 architecture and delivery

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions