diff --git a/archive-kanban/tickets/RET-13.md b/archive-kanban/tickets/RET-13.md new file mode 100644 index 00000000..e0bbe235 --- /dev/null +++ b/archive-kanban/tickets/RET-13.md @@ -0,0 +1,56 @@ +# RET-13 – Legal-Hold-Abfrage-Endpunkt für Module + +**Epic:** ⏳ Retention & WORM | **Rolle:** Backend | **Komplexität:** Mittel | **Aufwand:** 2 Personentage | **Welle:** 8 + +--- + +## Rolle +Du bist erfahrene Entwicklerin im Bereich Backend und baust NEXARCH Archive (Retention & WORM, Compliance & eDiscovery, Backup & Wiederherstellung, Kennzahlen), das sich an Alfresco, ecoDMS und restic/Borg orientiert. +Serverseitige Logik, Datenzugriff und Schnittstelle. Keine Geschäftslogik in der Oberfläche. + +## Auftrag +RET-03 hält Aufbewahrungssperren (Legal Hold) in `legal_holds`, aber nur als Go-Funktion (`deletionworkflow.IsOnLegalHold`). Module, die Objekte endgültig löschen (DMS: Papierkorb-Leerung, Ablauf der Papierkorbfrist), können die Sperre bisher nicht abfragen. Archive stellt dafür einen schreibgeschützten HTTP-Endpunkt bereit, den das DMS (INT-11, `retentionclient.CheckLegalHold`) bereits als Vertrag annimmt. + +**Technische Grundlage:** `GET /legal-hold?object_type=&object_reference=`, Antwort `200 {"on_hold": bool, "reason": string}`; Tenant-Registry-Abgleich (RET-12), Go + +## Produkt-DNA für diesen Bereich +**Übernehmen:** +- Alfresco/ecoDMS: Die Sperre wirkt vor jeder Löschung, unabhängig davon, welches Modul löscht. + +**Bewusst vermeiden:** +- Ein Aufrufer, der bei Unklarheit „nicht gesperrt“ annimmt. Archive liefert nur, was in der Datenbank steht. Alles Unklare (Fehler, Fremdmandant, fehlende Konfiguration) ist ein Fehlerstatus, nie `on_hold: false`. +- Vertrauen in den vom Modul mitgelieferten Tenant-Kontext (RET-12): Archive prüft ihn selbst und bindet ihn an die Instanz. + +## Ausgangslage +Setzt auf folgenden bereits fertigen Kacheln auf: RET-03, RET-05, RET-12. + +## Akzeptanzkriterien +Die Kachel gilt erst als umgesetzt, wenn alle Punkte erfüllt sind: +1. `GET /legal-hold` liefert für ein registriertes Objekt mit aktiver Sperre `on_hold: true` samt Grund, ohne aktive Sperre (nie gesperrt oder aufgehoben) `on_hold: false` +2. Ein fehlender oder fremder Tenant-Kontext, ein unbekannter Tenant, ein nicht erreichbares Tenant-Register und ein Datenbankfehler führen zu einem Fehlerstatus (400/403/503), nie zu `on_hold: false` +3. Die Abfrage ist rein lesend und mandantengetrennt: Sie liest ausschließlich die Datenbank der Instanz und ändert keine Sperre + +## 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. Test gegen echte Datenbank: gesperrtes, freigegebenes, nie gesperrtes und unbekanntes Objekt liefern die erwartete Antwort +2. Test: fremder Tenant, manipulierter Tenant-Header, Registry-Ausfall und Datenbankausfall werden nie als „nicht gesperrt“ beantwortet +3. Vertragstest: der DMS-`retentionclient` fragt den echten Archive-Handler ab (lokaler Lauf gegen Wegwerf-Datenbank) + +## Nicht Bestandteil dieser Kachel +Diese Punkte gehören ausdrücklich in andere Kacheln. Bereite höchstens die Schnittstelle dafür vor: +- `RET-03` Setzen und Aufheben von Sperren +- Dienst-zu-Dienst-Authentifizierung über Core-Modul-Tokens (Core-Board): Archive prüft optional ein Service-Token, bis Core es verbindlich ausliefert + +## 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: `RET-13: legal-hold-abfrage-endpunkt` +- Branch: `feature/ret-13-legal-hold-abfrage-endpunkt` +- Schrittweise committen, Branch pushen, dann anhalten. Kein Merge, kein Deploy. +- In der Beschreibung des Pull Request die durchgeführten Prüfungen mit Ergebnis auflisten.