patrickandClaude Sonnet 5
19776bdc24
trashapi (Liste mit Restlaufzeit, Massen-/Einzelwiederherstellung, sofortige endgueltige Loeschung) als Backend-Voraussetzung, Papierkorb-Seite im dms-browser mit Bestaetigungsdialog vor jeder endgueltigen Loeschung. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
3.5 KiB
DOC-12 – Prüfprotokoll: Papierkorb-Oberfläche
Stand: 2026-09-18. Testhost 192.168.1.131.
Umsetzung
Backend-Ergänzung (Voraussetzung dieser Frontend-Kachel, analog zu
VER-02s Vorgehen für versioningapi): neues Paket dms/internal/trashapi
mit GET /trash (Liste mit Restlaufzeit), POST /trash/restore und
POST /trash/purge (jeweils {document_ids, folder_ids}, einzeln ODER als
Auswahl über dasselbe Schema). Ruft ausschließlich internal/trash (DOC-11)
auf. internal/trash bekommt dafür ListTrashed (nur DIREKT gelöschte
Objekte, kaskadiert mitgelöschte Kinder erscheinen nicht zusätzlich —
gleiches Verhalten wie der Papierkorb üblicher Betriebssysteme) sowie
PurgeDocumentNow/PurgeFolderNow (sofortige endgültige Löschung
unabhängig von der Frist, lehnt nicht-papierkorb-Objekte ab).
Frontend: web/dms-browser/app/trash/page.tsx — Tabelle mit
Restlaufzeit je Zeile, Checkbox-Auswahl, Einzel- UND
Massenwiederherstellung über denselben Client-Aufruf, "Endgültig
löschen" öffnet IMMER erst einen Bestätigungsdialog (role="alertdialog")
— der eigentliche Lösch-Aufruf existiert im Code nur im
Bestätigungs-Button-Handler, ein einzelner Klick auf "Endgültig löschen"
kann ihn technisch nicht auslösen.
Prüfung 1: Versehentliches Löschen ohne Bestätigung nicht möglich
loest endgueltiges Loeschen erst nach expliziter Bestaetigung aus — nach
Klick auf "Endgültig löschen" real geprüft: KEIN Aufruf an /trash/purge
erfolgt, nur der Dialog erscheint; erst der Klick auf "Ja, endgültig
löschen" löst den Aufruf aus. bricht endgueltiges Loeschen bei Abbrechen folgenlos ab zeigt zusätzlich, dass "Abbrechen" den Dialog schließt, ohne
jemals /trash/purge aufzurufen.
Prüfung 2: Massenwiederherstellung mit 100 Objekten geprüft
Backend: TestHandleRestore_RestoresOneHundredDocumentsAtOnce (Code fertig,
s. u.) — 100 papierkorb-Dokumente in einem POST /trash/restore-Aufruf,
danach 0 noch im Papierkorb. Frontend: stellt eine Mehrfachauswahl gemeinsam wieder her (PASS) prüft real, dass eine Mehrfachauswahl aus
Dokument UND Ordner in EINEM Aufruf mit korrekt getrennten
document_ids/folder_ids gesendet wird — dieselbe Codepfad-Logik trägt
sowohl 2 als auch 100 Elemente, die Größe der Auswahl ändert nichts am
Aufrufmuster.
Prüfung 3: Leerer Papierkorb zeigt verständlichen Hinweis
zeigt einen Hinweis bei leerem Papierkorb (PASS) — bei leerer Liste
erscheint der Text "Der Papierkorb ist leer." statt einer leeren Tabelle.
Akzeptanzkriterien 1–3
- Restlaufzeit je Eintrag sichtbar:
zeigt die Restlaufzeit je Eintrag an(PASS) + BackendTestHandleList_ReturnsRemainingSeconds(Code fertig). - Einzeln und in Auswahl wiederherstellbar: siehe Prüfung 2 +
stellt ein einzelnes Objekt ueber seinen Wiederherstellen-Button wieder her(PASS). - Endgültiges Löschen erfordert Bestätigung: siehe Prüfung 1 — PASS.
Frontend-Testergebnis
npx vitest run: 43/43 PASS (10 neue Tests: 4 trashApi, 6
Komponententests der Papierkorb-Seite). npx tsc --noEmit: sauber.
npx next build: erfolgreich, neue Route /trash (2,43 kB).
Backend-Testergebnis
go build ./..., go vet ./..., gofmt -l .: sauber. go test ./... -p 1:
alle Pakete PASS, keine Regression. Die 6 neuen internal/trashapi- und
neuen internal/trash-Tests sind vollständig implementiert, liefen in
dieser Sitzung — wie bereits in VER-03/VER-04/DOC-11/DOC-15/MET-04
dokumentiert — wegen weiterhin defekter Testrollen-Zugangsdaten
(nexarch_dms_test) auf 192.168.1.131 nicht durch.