Wofür das Modul gedacht ist
Dokumente ist Teil des aktiven Modul-Katalogs und deckt einen klaren Ausschnitt des Produktalltags ab.
Projektdokumente in Ordnerstruktur verwalten, verteilen und teilen. Im Projektkontext bedeutet das, dass der Bereich nicht isoliert funktioniert, sondern direkt an Team, Status und weitere Projektbereiche anknüpft.
Dokumente 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.
Unterlagen strukturiert ablegen
Projektunterlagen bleiben im passenden Projektkontext und müssen nicht in separaten Dateisystemen gesucht werden.
Versionen und Freigaben sichern
Ordner, Versionen und Verteilung helfen, dass relevante Informationen beim richtigen Personenkreis landen.
Zusammenarbeit mit Kontext
Dokumente werden nicht isoliert verwaltet, sondern zusammen mit Aufgaben, Team und Projektdetails genutzt.
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.
Projekt-Infos
Projekt-Infos ergänzt Dokumente, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.
DetailsAufgaben
Aufgaben ergänzt Dokumente, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.
DetailsTeam
Team ergänzt Dokumente, 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
Zweitgrößtes Modul (20 Actions in 10 _all/scoped-Paaren). Enforcement-Mix aus Code (lib/projectDocumentLifecycle.ts), API-Pre-Check und mehrschichtigen RLS-Policies. Mehrere bemerkenswerte Backdoors und eine UPDATE-Policy, die SECHS Permissions zugleich gates.
Entwickler-Info aufklappen (6)
⚠ KRITISCHBackdoor: project_folders aktive Ordner-Sicht hat keine permission
project_folders_select (für aktive, nicht-gelöschte Ordner) gates nur auf tenant_id + deleted_at IS NULL — keine action-permission. Konsequenz: jeder Tenant-Member sieht alle aktiven Ordner aller Projekte, unabhängig von Projekt-Mitgliedschaft oder Modul-Visibility. Nur die TRASH-Sicht (project_folders_select_trash) ist sauber per manage_folders gegated. Mutations sind ebenfalls sauber gegated. Ähnliche Asymmetrie wie cost_adjustments und lv_position_assignees.
RLS: public.project_folders :: project_folders_select (no permission)RLS: public.project_folders :: project_folders_select_trash (manage_folders required)
⚡ MERKWÜRDIGEine UPDATE-Policy regiert sechs Permissions
project_documents_update gates über eine OR-Klausel mit SECHS Permission-Paaren gleichzeitig: edit_document/_all, share_document/_all, upload_version/_all. Plus uploaded_by-self-Bypass. RLS-seitig sind diese Permissions funktional gleichwertig — die semantische Unterscheidung lebt nur im API-Layer (welcher Endpoint welche Spalten setzt). Wer eine der sechs Permissions hat, kann die UPDATE-Policy für jeden Zweck passieren.
RLS: public.project_documents :: project_documents_update
⚡ MERKWÜRDIGVier Lese-Backdoors via Distribution
project_documents_select-Policy ist eine 4-Layer-OR: uploaded_by=self ODER document_distributions-Match (employee, project_team, leads_only Scope) ODER view_project_documents (scoped) ODER view_project_documents_all (global). Distribution wirkt damit als Lese-Bypass: wer ein Dokument auf irgendeine Weise in einem Distribution-Eintrag adressiert ist, sieht es — auch ohne view-permission.
RLS: public.project_documents :: project_documents_select
⚡ MERKWÜRDIGCode-only Enforcement für delete/restore/empty_trash
Die Soft-Delete-Aktionen (delete_document, restore_document, empty_trash) und ihre _all-Schwestern haben KEINE eigene RLS-Policy. Permission-Check läuft ausschließlich in lib/projectDocumentLifecycle.ts via TS-Helper-Funktionen. Wer die Lifecycle-Funktionen umgeht (direkt SQL UPDATE deleted_at), umgeht damit auch die Permission-Prüfung — die UPDATE-Policy fragt nur edit/share/upload_version ab, nicht delete.
lib/projectDocumentLifecycle.ts:274-276 (delete check)lib/projectDocumentLifecycle.ts:298-299 (restore check)lib/projectDocumentLifecycle.ts:316-317 (empty_trash check)
⚡ MERKWÜRDIGdistribute_document: Ersteller-Bypass
distributions_insert hat uploaded_by-self als OR-Path. Wer ein Dokument hochgeladen hat, kann es immer verteilen — auch ohne distribute_document-Permission. Pragmatisch (Ersteller bestimmt Empfängerkreis), aber für Audit-Logs nicht offensichtlich.
RLS: public.document_distributions :: distributions_insert
Stage-1-Coupling (bestehend)
project_documents.upload_document braucht projects.view_all_projects (Endpoint lädt Zielprojekt). view_project_documents braucht ebenfalls view_all_projects.
lib/permission-dependencies.ts