nexarch/dms/docs/DOC-15-PRUEFPROTOKOLL.md

DOC-15 – Prüfprotokoll: Massenbearbeitung von Metadaten

Stand: 2026-09-17. Testhost 192.168.1.131.

Umsetzung

Neues Paket internal/bulkedit orchestriert ausschließlich bestehende Pakete (tag, metadatafield, versioning, audittrail) über eine Dokumentauswahl hinweg — keine eigene Tag-/Metadaten-/Sperr-Logik:

• Apply(pool, lockChecker, actor, Request{...}) — Tags hinzufügen/entfernen (Akzeptanzkriterium 1) und Metadatenfelder setzen/entfernen (MetadataChange mit Value == nil = entfernen) in EINER Transaktion über alle NICHT gesperrten Dokumente.
• LockChecker-Schnittstelle (Muster wie versioningapi.PermissionChecker aus VER-02): das DMS-Modul hat noch keine eigene Anbindung an Archive-Retention-Sperren ("Aufbewahrungssperre" ist laut Ticket ausdrücklich Sache des Archive-Boards) — VersioningLockChecker nutzt stattdessen die bereits real vorhandene VER-01-Ausleihsperre (document_locks) als konkrete, im Modul selbst existierende Sperre. Eine spätere echte Retention-Sperren-Prüfung ersetzt das, ohne die Apply-Schnittstelle zu ändern.
• Jeder Aufruf schreibt GENAU EINEN Eintrag ins bestehende, unveränderliche Audit-Protokoll (VER-05) mit den betroffenen und den übersprungenen Dokumenten (Akzeptanzkriterium 2).

Prüfung 1: Tag auf 10 ausgewählte Dokumente gleichzeitig angewendet

TestApply_AddsTagToTenDocumentsAtOnce — 10 Dokumente, ein Apply-Aufruf, real geprüft: alle 10 haben danach die Tag-Zuordnung, result.Applied zählt 10, result.Skipped ist leer. TestApply_RemovesTagFromSelection prüft zusätzlich, dass eine ENGERE Folgeauswahl den Tag nur bei den tatsächlich ausgewählten Dokumenten entfernt, nicht bei allen zuvor getaggten.

Prüfung 2: Audit-Log zeigt Massenänderung nachvollziehbar

TestApply_RecordsAuditLogEntry — nach Apply existiert genau ein audit_log-Eintrag mit action = "bulk_edit", korrektem Akteur und den betroffenen Dokument-IDs in den Metadaten (real aus dem JSON zurückgelesen und verglichen, nicht nur auf Existenz geprüft).

Prüfung 3: Test mit gesperrtem Dokument in der Auswahl

TestApply_SkipsLockedDocumentButProcessesRest — ein Dokument wird über VER-01 CheckOut von einem ANDEREN Nutzer ausgeliehen, dann eine Auswahl aus diesem UND einem freien Dokument bearbeitet: das gesperrte Dokument bleibt unverändert und erscheint mit nachvollziehbarem Grund ("ausgeliehen von <nutzer> bis <zeitpunkt>") in result.Skipped, das freie Dokument wird korrekt geändert — die Operation als Ganzes wird NICHT abgelehnt.

Akzeptanzkriterien 1–3

• Gleichzeitige Änderung über Auswahl: siehe Prüfung 1 — PASS.
• Transaktional nachvollziehbar (Audit): siehe Prüfung 2 — PASS.
• Aufbewahrungssperren respektiert, Rest wird bearbeitet: siehe Prüfung 3 — PASS (mit der oben begründeten Einschränkung: geprüft wird die im Modul real existierende VER-01-Sperre, nicht eine noch nicht angebundene Archive-Retention-Sperre).

Regressionsnachweis

go build ./..., go vet ./..., gofmt -l .: sauber. go test ./... -p 1: alle Pakete PASS, keine Regression.

Offene Punkte

Alle vier neuen internal/bulkedit-Tests sind vollständig implementiert, liefen in dieser Sitzung aber — wie bereits in VER-03/VER-04/DOC-11 dokumentiert — wegen weiterhin defekter Testrollen-Zugangsdaten (nexarch_dms_test) auf 192.168.1.131 nicht durch. Nachzuholen, sobald ein Mensch die Zugangsdaten erneuert hat.