Wofür das Modul gedacht ist
Papierkorb ist Teil des aktiven Modul-Katalogs und deckt einen klaren Ausschnitt des Produktalltags ab.
Tenantweiter Überblick über gelöschte Dateien mit Vorschau, Wiederherstellung und finaler Löschung nach Ablauf der Wiederherstellungsfrist. Im tenantweiten Kontext sorgt der Bereich dafür, dass wiederkehrende Entscheidungen, Stammdaten oder Übersichten nicht in Nebensysteme ausweichen müssen.
Papierkorb ist als eigenständiger Produktbaustein gedacht. Gerade deshalb lohnt sich ein Blick darauf, wie der Bereich mit Rollen, Datenkontext und angrenzenden Modulen zusammenspielt.
Typische Einsatzfälle
Diese Situationen zeigen, wann der Bereich in einem sauberen Rollout oder im laufenden Betrieb konkret Mehrwert liefert.
Versehentlich gelöschte Dateien sichern
Dokumente, Anhänge und Nachweise bleiben nach dem Löschen zunächst im Papierkorb sichtbar und können gezielt wiederhergestellt werden.
Backup für spätere Wiederherstellungen
Zusätzlich zum Papierkorb werden Dateien serverseitig gesichert, damit Inhalte bei Bedarf auch nach der regulären Frist noch auf Anfrage wiederherstellbar bleiben.
Inhalte vor der Rückgabe prüfen
Mit Preview und Download lässt sich kontrollieren, ob wirklich die richtige Datei wiederhergestellt oder weiter abgestimmt werden soll.
Wie das Modul mit anderen Bereichen zusammenspielt
struct-i-vio ist als zusammenhängende Plattform gedacht. Diese Module liegen fachlich am nächsten bei diesem Bereich.
Dokumente
Dokumente ergänzt Papierkorb, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.
DetailsAufgaben
Aufgaben ergänzt Papierkorb, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.
DetailsAusgaben
Ausgaben ergänzt Papierkorb, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.
DetailsBerechtigungen und Sichtbarkeit
Die öffentliche Dokumentation beschreibt die Logik auf Produktniveau - nicht als technische Policy-Liste, sondern als Rollout-Leitfaden.
Best Practices
So bleibt der Bereich bei Einführung und Nutzung anschlussfähig an den restlichen Produktfluss.
Entwickler Info
Cross-Modul-Gatekeeper. 4 Permissions ohne _all/scoped-Pair. Berührt 9 öffentliche + 2 interne Datei-Lifecycle-Typen quer durch alle Module mit Anhängen (project_documents, project_tasks, transaction_attachments, hour/expense_attachments, invoices, subcontracts, employee_absences). Die 4 Trash-Permissions sind das "Außentor" — die "Innentore" liegen in den Quell-Modulen.
Entwickler-Info aufklappen (5)
⚠ KRITISCHRestore + Purge sind notwendig, aber nicht hinreichend
Wer file_trash.restore_trash bzw. purge_trash hat, kann NICHT automatisch jede Datei wiederherstellen oder endgültig löschen. /api/trash/restore und /api/trash/purge prüfen ZUSÄTZLICH per record_type die Modul-spezifische edit-Permission: invoice_attachments → invoices.edit_invoice OR _all, subcontract_attachments → contracts.edit_contract OR _all. Für die anderen 7 Record-Types lebt die Coupling in lib/fileLifecycle.ts und den jeweiligen Lifecycle-Helpers (z.B. taskFileLifecycle, projectDocumentLifecycle).
pages/api/trash/restore.ts:69-133pages/api/trash/purge.ts:69-133lib/fileLifecycle.tslib/fileTrash.ts:68-88 (TRASH_RECORD_TYPES)
⚠ KRITISCHLive-Preview muss Coupling visualisieren
Beim Schließen einer file_trash-Permission im Admin-UI muss die Preview die 9+2 Quell-Module mit anzeigen, damit der Admin versteht: "Wer das schließt, blockiert auch invoice/contract/document/task-Restore-Pfade — selbst wenn die Modul-edit-Permissions offen sind." Beim Öffnen analog: "Diese Permission allein reicht nicht — der User braucht auch edit_invoice etc."
Preview-URL ist 1h gültig nach Generation
preview_trash erzeugt eine signed-URL via supabaseService-Storage für 60 Minuten. Einmal generierte URLs sind unabhängig von späteren Permission-Änderungen gültig — wer einen Vorschau-Link kopiert hat, kann ihn bis zum Ablauf nutzen.
pages/api/trash/preview.ts:71-83
view_trash zeigt RLS-gefilterte Liste, nicht alle Records
Die Trash-Liste ist via RLS auf eigene Records bzw. solche aus Projekten mit Mitgliedschaft gefiltert. view_trash öffnet nur das Tor zur Liste, nicht den globalen Tenant-Trash. Wer alle Trash-Items sehen will, braucht zusätzlich die _all-Permissions der jeweiligen Quell-Module (z.B. view_project_documents_all).
Purge ist permanent destructive
purge_trash entfernt sowohl den DB-Record als auch das Storage-Objekt aus attachments-Bucket. Kein Undo, keine zweite Trash-Stufe. Bewusste UX-Entscheidung — der Papierkorb selbst ist die Wiederherstellungs-Stufe.
