nexarch/archive/docs/CMP-07-PRUEFPROTOKOLL.md

CMP-07 – Prüfprotokoll: DSGVO-Löschantrag (Recht auf Löschung, Art. 17)

Voraussetzung RET-03, RET-05, CMP-02, CMP-06 – alle bereits Fertig.

Bekannten Fehler vermieden (Ticket-Vorgabe)

dsgvorequest.ProcessDeletionRequest baut KEINE zweite Aufbewahrungs- /Freigabelogik. Es ruft ausschließlich auf:

• dpreport.SubjectReport (CMP-02) für die Suche,
• deletionworkflow.IsOnLegalHold (RET-03) für die Sperrprüfung,
• deletionapproval.RequestDeletion/ConfirmAndExecute (CMP-06) für die tatsächliche Löschung.

Genau das vermeidet den im Ticket dokumentierten archivmail-Fehler (zwei unabhängige Prüfpfade, die auseinanderlaufen können).

Additive Erweiterung von CMP-02 (bereits Fertig)

dpreport.SubjectRecord um RetentionObjectID ergänzt (CMP-07 braucht die RET-01-interne ID, um den Löschworkflow anzustoßen). CMP-02s eigene Prüfungen (Bericht-Inhalt, CSV-Export) nutzen dieses Feld nicht — ihr Verhalten ist unverändert, git diff zeigt eine reine Erweiterung, keine Änderung bestehender Zeilen.

Umsetzung

• archive/migrations/0011_dsgvo_decision_log.up/down.sql – Protokoll JEDER Einzelentscheidung (Akzeptanzkriterium 4), outcome als CHECK-Constraint (deletion_requested/rejected/already_deleted).
• archive/internal/dsgvorequest.ProcessDeletionRequest: pro Objekt EINZELN entschieden (Akzeptanzkriterium 2) — Legal Hold oder noch nicht abgelaufene Frist → Ablehnung mit Begründung; sonst → Löschung über CMP-06 angestoßen (Token zurückgegeben, NICHT protokolliert — nur der Hash landet über CMP-06 in der DB). Jede Entscheidung wird vor Rückgabe protokolliert.

Prüfungen

#	Prüfung	Ergebnis
1	Löschantrag für eine Testperson mit gemischtem Datenbestand liefert exakt eine Löschung und eine begründete Ablehnung	bestanden – TestProcessDeletionRequest_MixedDatasetYieldsOneDeletionOneRejection: genau 1 deletion_requested (richtiges Objekt) + 1 rejected mit Begründung. Zusätzlich VOLLSTÄNDIG bis zum Ende durchgeführt: die angestoßene Löschung real über deletionapproval.ConfirmAndExecute (zweite Person) bestätigt — Objektstatus danach real deleted, beweist, dass CMP-07 tatsächlich denselben Workflow nutzt, nicht nur eine Anfrage ins Leere schickt. Protokoll (dsgvo_decision_log) enthält beide Entscheidungen
2	Aufbewahrungssperre (Legal Hold) verhindert die Löschung auch bei bereits abgelaufener regulärer Frist	bestanden – TestProcessDeletionRequest_LegalHoldBlocksEvenExpiredObject: Objekt mit Status expired (Frist bereits abgelaufen) UND aktiver Sperre → rejected, Status bleibt real unverändert expired, keine Löschung angestoßen
3	Löschantrag für einen Tenant führt nachweislich zu keiner Aktion an Objekten eines anderen Tenants	bestanden – TestProcessDeletionRequest_TenantIsolation: real gegen zwei physisch getrennte Tenant-Datenbanken (tenant_acme/tenant_globex, wie schon bei CMP-02) — Objekt in Tenant A angelegt, Löschantrag für dieselbe data_subject_ref gegen Tenant B liefert 0 Entscheidungen, Tenant As Objekt bleibt real unverändert

Build/Test-Ergebnis (192.168.1.131)

go build ./...  -> clean
go vet ./...    -> clean
golangci-lint run ./...  -> 0 issues
go test ./... -p 1  -> alle Archive-Pakete bestanden (inkl. dsgvorequest, dpreport)

Migration 0011_dsgvo_decision_log real auf dms_tenant_test angewendet.

Gesamtergebnis

Bestanden. Alle vier Akzeptanzkriterien und alle drei Pflichtprüfungen real erfüllt — inklusive einer vollständig bis zur tatsächlichen Vernichtung durchgeführten Löschung über den echten Vier-Augen-Workflow. Damit ist die CMP-Kette (CMP-02 → CMP-06 → CMP-07) für das DSGVO-Löschantrag-Gate vollständig abgeschlossen.