Plattform & Einstieg · Global

Papierkorb: wie gelöschte Dateien sicher wiederherstellbar bleiben.

Tenantweiter Überblick über gelöschte Dateien mit Vorschau, Wiederherstellung und finaler Löschung nach Ablauf der Wiederherstellungsfrist. Das Modul hat einen eigenen tenantweiten Einstiegspfad und sammelt gelöschte Dateien aus mehreren Arbeitsbereichen an einer gemeinsamen Stelle: /trash.

  • Der Papierkorb sammelt gelöschte Dateien tenantweit an einer Stelle, statt Löschvorgänge auf einzelne Fachbereiche zu verteilen.
  • Gelöschte Unterlagen bleiben im Regelfall während der Wiederherstellungsfrist direkt im Produkt verfügbar und können vor einer finalen Löschung geprüft werden.
  • Zusätzlich gibt es für Dateien ein serverseitiges Backup. Nach Rückfrage können gesicherte Inhalte bis zu ein Jahr später wiederhergestellt werden.
  • Welche Aktionen möglich sind, hängt an Rollen sowie an der Frage, ob eine Datei nur eingesehen, wiederhergestellt oder endgültig entfernt werden darf.
Modulzweck

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.

Das Modul hat einen eigenen tenantweiten Einstiegspfad und sammelt gelöschte Dateien aus mehreren Arbeitsbereichen an einer gemeinsamen Stelle: /trash.
Praxisbezug

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.

Modulverbindungen

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.

Sichtbarkeit

Berechtigungen und Sichtbarkeit

Die öffentliche Dokumentation beschreibt die Logik auf Produktniveau - nicht als technische Policy-Liste, sondern als Rollout-Leitfaden.

Die Sichtbarkeit wird tenantweit über das eigene Modul Papierkorb freigeschaltet und sollte nur Rollen erhalten, die gelöschte Inhalte wirklich prüfen müssen.
Ansicht, Preview und Wiederherstellung können breiter freigegeben werden als die endgültige Löschung. So bleibt Fehlbedienung korrigierbar, ohne destruktive Rechte breit auszurollen.
Purge ist die schärfste Aktion: Sie bleibt enger freigegeben und ist erst nach Ablauf der Wiederherstellungsfrist möglich.
Da der Papierkorb Dateien aus mehreren Arbeitsbereichen zusammenführt, sollte die Freigabe immer mit Verantwortlichkeiten für Dokumente, Belege und Projektanhänge abgestimmt werden.
Empfohlener Einsatz

Best Practices

So bleibt der Bereich bei Einführung und Nutzung anschlussfähig an den restlichen Produktfluss.

Den Papierkorb als Sicherheitsnetz lesen, nicht als Dauerablage. Dateien gehören nach der Prüfung wieder in den Fachbereich oder in den finalen Löschprozess.
View, Preview und Restore können breiter vergeben werden als Purge, damit Teams Fehlklicks korrigieren können, endgültige Löschungen aber eng gesteuert bleiben.
Die Wiederherstellungsfrist von bis zu 30 Tagen im Team klar kommunizieren, damit gelöschte Belege oder Unterlagen rechtzeitig geprüft werden.
Wenn die reguläre Frist bereits abgelaufen ist, kann das zusätzliche Dateibackup relevant werden: Gesicherte Dateien bleiben bis zu ein Jahr auf Anfrage wiederherstellbar.
Tiefer einsteigen

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-133
  • pages/api/trash/purge.ts:69-133
  • lib/fileLifecycle.ts
  • lib/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.