API · v1 · stabil
CODEMETA OSDeveloper Center
Konsole öffnen
Konzept

Audit-Historie

Lesedauer · 8 Min.Aktualisiert · 2026-05-01

Codemeta OS persistiert für jede Mutation an einer Entity einen Audit-Eintrag mit einem JSON-Patch nach RFC 6902. Der Patch beschreibt die Änderung als Sequenz von add/remove/replace-Operationen.

Was steht im Audit-Eintrag?

Jeder Eintrag enthält:

  • entityId – die UUID der Entity, die geändert wurde.
  • entitySchema – z. B. ticket, kb_article.
  • operation – create, update, delete, restore.
  • patch – der RFC-6902-JSON-Patch.
  • actor – wer die Änderung ausgelöst hat (User-ID oder System).
  • at – Zeitstempel im ISO-8601-Format.
  • tenantId – natürlich.

Beispiel-Patch

Aus einem Update, das die Priorität eines Tickets von normal auf high setzt und einen neuen Tag anhängt:

[
  { "op": "replace", "path": "/priority", "value": "high" },
  { "op": "add", "path": "/tags/-", "value": "eskalation" }
]

Der Patch ist so ausgeführbar, dass applyPatch(prevState, patch) === nextState ergibt. Sie können also den Zustand vor und nach jeder Änderung deterministisch rekonstruieren, indem Sie die Patches in der richtigen Reihenfolge anwenden.

Audit-Trail abrufen

Pro Entity gibt es eine Timeline-Route. Mit ?filter=history bekommen Sie nur die Audit-Einträge:

curl "https://os.codemeta.de/api/v1/tickets/<id>/timeline?filter=history" \
  -H "X-Tenant-Id: $TENANT" \
  -b cookies.txt

Die Timeline ist chronologisch absteigend; älteste Einträge stehen am Ende. Geblättert wird per Cursor über meta.nextCursor — siehe Pagination.

Warum überhaupt ein Patch?

  • Auditierbarkeit – jede Änderung ist nachvollziehbar, ohne dass Sie alle Versionen einer Entity speichern müssen.
  • Wenig Speicher – Patches sind kompakt, ein voller Snapshot wäre teuer.
  • Reproduzierbarkeit – Sie können den Zustand einer Entity zu jedem Zeitpunkt rekonstruieren, indem Sie alle Patches bis dahin anwenden.

Verwandte Konzepte

Suche