Wofür das Modul gedacht ist
Terminplan ist Teil des aktiven Modul-Katalogs und deckt einen klaren Ausschnitt des Produktalltags ab.
Projektterminplanung mit Vorgängen und Baselines. Im Projektkontext bedeutet das, dass der Bereich nicht isoliert funktioniert, sondern direkt an Team, Status und weitere Projektbereiche anknüpft.
Terminplan 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.
Projektarbeit koordinieren
Terminplan unterstützt dabei, operative Arbeit, Termine oder Dokumentation im Projekt zusammenzuführen.
Abstimmung im Team entlasten
Wenn Aufgaben, Informationen und Kontext an einem Ort liegen, werden Abstimmungen schneller und verbindlicher.
Fortschritt sichtbar machen
Projektmodule helfen dabei, Statusveränderungen nachvollziehbar zu halten statt nur reaktiv zu reagieren.
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.
Aufgaben
Aufgaben ergänzt Terminplan, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.
DetailsBautagebuch
Bautagebuch ergänzt Terminplan, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.
DetailsÜbersicht
Übersicht ergänzt Terminplan, 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
RLS-only Modul mit 9 Actions auf 5 Tabellen (milestones, schedule_calendar, schedule_baselines, schedule_baseline_items, schedule_dependencies). KEIN API-Pre-Check in den schedule-* Endpoints. Drei Asymmetrien zu dokumentieren: schedule_calendar gates INSERT als edit_activity, create_baseline ist divergent zwischen RPC und RLS, _all-Varianten gibt es nur für milestones.
Entwickler-Info aufklappen (4)
⚠ KRITISCHAsymmetrie #1: schedule_calendar_insert nutzt edit_activity
Die RLS-Policy schedule_calendar_insert_project gates edit_activity, nicht create_activity. Wer create_activity hat aber kein edit_activity, kann KEINE kalendarischen Einträge anlegen — obwohl der Action-Name das suggeriert. Schedule-Calendar behandelt INSERT semantisch wie UPDATE (beide via edit_activity gegated). Andere Schedule-Tabellen (milestones, baselines, dependencies) folgen dem Standard-Pattern.
supabase/migrations/20251210234001_squash_baseline.sql:25339
⚠ KRITISCHAsymmetrie #2: create_baseline divergente Enforcement
Die RPC create_schedule_baseline() prüft create_baseline (squash:4966). Die API /api/projects/[id]/schedule-baselines POST nutzt ausschließlich diese RPC. ABER: schedule_baselines_insert_project (RLS) gates create_activity, NICHT create_baseline! Wer create_activity hat aber kein create_baseline, kann via direktem PostgREST-Insert auf schedule_baselines eine Baseline anlegen — die RPC blockiert ihn aber. In der UI ist nur die RPC erreichbar, daher praktisch irrelevant. Bei API-Konsumenten (mobile App, externe Skripte) gilt der Bypass.
supabase/migrations/20251210234001_squash_baseline.sql:4945-5093 (RPC)supabase/migrations/20251210234001_squash_baseline.sql:25300 (RLS)
Asymmetrie #3: _all-Varianten nur für milestones
create_activity_all, edit_activity_all und delete_activity_all gates AUSSCHLIESSLICH die milestones-Tabellen. Für schedule_baselines, schedule_calendar und schedule_dependencies existieren keine _all-Policies — globale Operationen sind auf Meilensteine beschränkt. Wer global Calendar-Einträge editieren möchte, kann das nicht — auch nicht mit edit_activity_all.
Reine RLS-Verdrahtung — keine API-Pre-Checks
Wie project_tasks: Die schedule-* API-Endpoints führen keine can_perform_action-Checks durch. Die Permission-Enforcement geschieht ausschließlich über RLS-Policies. User ohne Permission sehen PostgREST-42501-Antworten, nicht klare 403-Strings. Ausnahme: create_baseline läuft über die RPC und liefert eine klare "Keine Berechtigung zum Erstellen von Baselines"-Exception.