Create major_incident

Legt einen Major Incident an. Im Gegensatz zum normalen Ticket löst diese Operation in derselben Transaktion drei zusätzliche Effekte aus:

1. Customer-Tenants, die im Kundenkreis betroffen sind, erhalten eine Broadcast-Nachricht (sichtbar in deren Self-Service-Portal).
2. Der konfigurierte Eskalations­workflow startet (Telefonkette, Slack-Webhook, ggf. Statusseite-Update).
3. Ein Webhook-Event incident.major.created wird in die Outbound-Queue gestellt.

Sie sollten diese Route nicht für gewöhnliche Störungen nutzen — die Audit-Klasse ist anders, und die Customer-Tenants sehen sie sofort.

Datenmodell

Diese Operation arbeitet auf der Entität Major Incident (major_incident). Alle 13 Felder — Typ, Validierung, Pflichtangabe, Beziehungen — stehen in der Schema-Referenz.

• Pflichtfelder: title, severity, status
• Server-verwaltet: _id, schema, schemaVersion, tenantId, version, createdAt, updatedAt, createdBy, updatedBy, deletedAt, deletedBy, childTicketIds — diese Felder vergibt die Plattform; im Request werden sie verworfen.

Beispiel

curl -X POST https://api.codemeta-os.de/v1/major_incidents \
  -H "X-Tenant-Id: $TENANT" \
  -b cookies.txt

const result = await cm.major_incidents.post();

Best Practice

Lassen Sie den Eskalations­workflow vorab anlegen (POST /v1/incidents/escalation-policies) und referenzieren Sie ihn hier nur per escalationPolicyId. So bleibt das Anlegen schnell und deterministisch — der schwierige Teil (Kontaktketten, Fall­back-Pfade) wird einmal modelliert, nicht pro Incident.

Antwortcodes

Verwandte Konzepte

• Multi-Tenancy
• Audit-Historie

Verwandte Tutorials

• Webhook absichern