Wofür das Modul gedacht ist
Stunden ist Teil des aktiven Modul-Katalogs und deckt einen klaren Ausschnitt des Produktalltags ab.
Projektstunden einsehen, freigeben und im Projektkontext steuern. Im Projektkontext bedeutet das, dass der Bereich nicht isoliert funktioniert, sondern direkt an Team, Status und weitere Projektbereiche anknüpft.
Stunden hängt fachlich an Cash-Flow. Dadurch ist für Nutzer sofort klar, in welchem größeren Ablauf das Modul seinen Platz hat.
Typische Einsatzfälle
Diese Situationen zeigen, wann der Bereich in einem sauberen Rollout oder im laufenden Betrieb konkret Mehrwert liefert.
Schnell Orientierung gewinnen
Stunden bietet einen klaren Einstieg in den jeweiligen Arbeitsbereich.
Mit dem restlichen Produkt verzahnen
Der Bereich arbeitet am besten, wenn Verantwortlichkeiten, Sichtbarkeit und angrenzende Module gemeinsam gedacht werden.
Rollout schrittweise aufbauen
Im Rollout sollte zuerst der relevante Kernnutzen sichtbar sein und später gezielt erweitert werden.
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.
Cash-Flow
Cash-Flow ergänzt Stunden, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.
DetailsBudget
Budget ergänzt Stunden, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.
DetailsStundenmatrix
Stundenmatrix ergänzt Stunden, 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
Größtes Backbone-fähiges Modul (11 Actions). Mehrere bestehende cross_module-Regeln in MANUAL_PERMISSION_DEPENDENCIES (edit/approve → projects.view_all_projects, view-before-edit, edit-before-delete). Mischung aus API+RPC, RLS-only und einem TRULY UNBOUND-Toggle.
Entwickler-Info aufklappen (4)
⚠ KRITISCHrevoke_approval_all ist TRULY UNBOUND
Die _all-Variante zu revoke_approval ist nirgends enforced — kein Code, keine RPC, keine RLS, keine View referenzieren sie. Symmetrische Karteileiche zu anderen _all-Toggles im System (delete_all in project_payments, view_fund/view_all_requests in company_fund). Toggle wirkungslos.
scripts/probes/probe-project-hours-module.js
⚡ MERKWÜRDIGapprove_project_hours_all ist nur über Trigger erreichbar
Im Code wird approve_project_hours (project-scoped) explizit per can_perform_action geprüft. Die _all-Variante hat KEINEN direkten Callsite — sie wird nur indirekt durch den check_approval_permission Trigger auf hours geprüft, wenn der Status von "submitted" auf "approved" wechselt und der scoped-Pfad fehlschlägt. In Praxis greift sie nur als Trigger-Fallback bei Hour-UPDATE.
DB Trigger: check_approval_permission auf public.hours
⚡ MERKWÜRDIGreassign_direct ist Trigger-enforced — UI darf irreführend wirken
check_reassign_direct_permission ist ein Trigger auf hours, der bei project_id-Wechsel feuert. Wer die Permission nicht hat, sieht den "Direkt umbuchen"-Knopf trotzdem im UI; das DB-UPDATE wirft dann RAISE EXCEPTION. Schöner wäre ein usePermissions-basierter Frontend-Gate.
pages/api/entries/reassign.ts:66DB Trigger auf public.hours
Saubere _all/scoped-Verdrahtung mit zwei Stage-1-Couplings
view, edit, delete, approve folgen alle dem etablierten Pattern: separate Policies pro (CMD, scope), die Postgres ORt. Bestehende cross_module-Regeln in MANUAL_PERMISSION_DEPENDENCIES: edit_project_hours + approve_project_hours brauchen projects.view_all_projects (Endpoint lädt das Zielprojekt zur Validierung).
lib/permission-dependencies.tsRLS: hours_select_all/_project, hours_update_all/_project, hours_delete_all/_project