From 49d4e36f67b873a9d53ba277e7bc70ae699a6829 Mon Sep 17 00:00:00 2001 From: patrick Date: Sat, 19 Sep 2026 01:10:00 +0200 Subject: [PATCH] dms-kanban: Ticket VER-09 (Audit-Ereignisse fuer alle relevanten Aktionen) anlegen Co-Authored-By: Claude Sonnet 5 --- dms-kanban/tickets/VER-09.md | 58 ++++++++++++++++++++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 dms-kanban/tickets/VER-09.md diff --git a/dms-kanban/tickets/VER-09.md b/dms-kanban/tickets/VER-09.md new file mode 100644 index 00000000..26f16a55 --- /dev/null +++ b/dms-kanban/tickets/VER-09.md @@ -0,0 +1,58 @@ +# VER-09 – Audit-Ereignisse für alle relevanten Aktionen + +**Epic:** 🔄 Versionierung & Audit | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 3 Personentage | **Welle:** 12 + +--- + +## Rolle +Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH DMS (Dokumentenkern, Suche & OCR, Metadaten, Versionierung, Integration/API), das sich an paperless-ngx, Alfresco, Docspell und ecoDMS orientiert und bekannte Fehler aus archivdms (siehe known-issues-archivdms.md) bewusst vermeidet. +Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche. + +## Auftrag +VER-05 liefert das manipulationssichere Audit-Log (Hash-Kette, Append-only), aber außer Bulk-Edit (VER-02-Umfeld) und Malware-Scan (DOC-17) schreibt keine Aktion hinein. Gefunden bei der Vorbereitung von QA-08 (2026-09-19): Upload, neue Revision, Wiederherstellen, Signieren, Download-URL/Download, Papierkorb (löschen/wiederherstellen/endgültig löschen), Metadaten- und Tag-Änderungen, Export-Anforderung und automatische Endgültig-Löschung erzeugen keinen Eintrag. Alle diese Aktionen protokollieren, mit Akteur, Objekt und Aktion, im selben Protokoll. + +**Technische Grundlage:** `internal/audittrail` (Append), Akteur je Aufrufkontext (Parameter `caller` nach dem in `versioningapi`/`downloadapi` etablierten Muster, Systemakteur für automatische Vorgänge) + +## Produkt-DNA für diesen Bereich +**Übernehmen:** +- Alfresco: lückenloser Audit-Trail als Voraussetzung für Revisionssicherheit. + +**Bewusst vermeiden:** +- Ein Protokoll, das nur formal manipulationssicher ist, aber die eigentlichen Aktionen nicht enthält. +- Stilles Weiterlaufen ohne Protokolleintrag: schlägt das Protokollieren fehl, ist das ein Fehler, kein Log-Hinweis. + +## Ausgangslage +Setzt auf folgenden bereits fertigen Kacheln auf: VER-05, VER-07, VER-08, DOC-01, DOC-11, DOC-15, DOC-16. + +## Akzeptanzkriterien +Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind: +1. Jede der folgenden Aktionen erzeugt genau einen Protokolleintrag mit Akteur, Objekt und Aktion: Dokument angelegt (Upload), neue Revision, Revision wiederhergestellt, Dokument signiert, Download-URL ausgestellt, Download durchgeführt, Dokument in Papierkorb, aus Papierkorb wiederhergestellt, endgültig gelöscht (manuell und automatisch), Metadaten geändert, Tag zugewiesen/entfernt, Export angefordert +2. Das Protokollieren schlägt sichtbar fehl (Fehler an den Aufrufer), wenn der Eintrag nicht geschrieben werden kann +3. Rein lesende Vorschau-Zugriffe (`GET /documents/{id}/content`) werden bewusst nicht protokolliert; die Entscheidung ist dokumentiert +4. Die Hash-Kette bleibt nach allen Aktionen lückenlos gültig (`VerifyChain`) + +## Prüfungen vor der Abnahme +Führe jede Prüfung tatsächlich durch und halte das Ergebnis schriftlich fest. Nicht durchgeführte Prüfungen zählen als offen: +1. Referenzablauf über alle genannten Aktionen: das Protokoll enthält exakt die erwarteten Einträge in der erwarteten Reihenfolge +2. Test: Protokollierung nicht möglich (z. B. Rolle ohne INSERT-Recht) — die Aktion meldet einen Fehler +3. `VerifyChain` nach dem Referenzablauf fehlerfrei + +## Nicht Bestandteil dieser Kachel +Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor: +- `QA-08` Revisionssicherheits-Prüfung (nutzt diese Einträge) +- Atomarität von Aktion und Protokolleintrag in einer Transaktion (bekannte Einschränkung, siehe Prüfprotokoll) +- Authentifizierte Akteursidentität aus dem Core (bis dahin `caller`-Parameter) + +## Arbeitsweise +1. Lies zuerst den bestehenden Code der Vorbedingungen und halte dich an die dort etablierten Muster. +2. Setze die kleinste Lösung um, die alle Akzeptanzkriterien erfüllt. Kein Umbau angrenzender Bereiche. +3. Schreibe zu jedem Akzeptanzkriterium mindestens einen automatisierten Test. +4. Führe alle Prüfungen aus und dokumentiere Zielwert und Ergebnis. +5. Deutschsprachige Oberflächentexte, englischsprachige Bezeichner im Code. +6. Keine Zugangsdaten, Schlüssel oder Verbindungszeichenfolgen im Code – ausschließlich über Umgebungsvariablen. + +## Abschluss +- Commit-Nachricht: `VER-09: audit-ereignisse-aller-relevanten-aktionen` +- Branch: `feature/ver-09-audit-ereignisse-aller-relevanten-aktionen` +- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy. +- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.