Plattform & Einstieg · Global

Stunden: wann das Modul im Produktalltag Sinn ergibt.

Persönliche Stundenerfassung für zugewiesene Projekte. Das Modul hat einen eigenen Einstiegspfad innerhalb des Produkts: /hours.

  • Stunden erklärt kompakt, wofür der Bereich gedacht ist und wann er im Arbeitsalltag relevant wird.
  • Der Bereich spielt in der Praxis besonders mit Stunden und Stundenmatrix zusammen.
  • Rollen, Sichtbarkeit und angrenzende Bereiche bestimmen, wie gut das Modul im Alltag funktioniert.
Modulzweck

Wofür das Modul gedacht ist

Stunden ist Teil des aktiven Modul-Katalogs und deckt einen klaren Ausschnitt des Produktalltags ab.

Persönliche Stundenerfassung für zugewiesene Projekte. Im tenantweiten Kontext sorgt der Bereich dafür, dass wiederkehrende Entscheidungen, Stammdaten oder Übersichten nicht in Nebensysteme ausweichen müssen.

Stunden 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 Einstiegspfad innerhalb des Produkts: /hours.
Praxisbezug

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.

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 bzw. organisationsweit freigeschaltet und sollte zu Rolle und Verantwortungsbereich passen.
Gerade bei Teamarbeit lohnt sich ein abgestuftes Modell aus Sichtbarkeit, Bearbeitung und Freigaben statt einer pauschalen Alles-oder-Nichts-Freigabe.
Empfohlener Einsatz

Best Practices

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

Mit einem klaren Kernnutzen starten und nur die angrenzenden Bereiche freischalten, die den Alltag direkt entlasten.
Das Modul mit Rollen, Projektkontext und Navigation so verzahnen, dass Nutzer ohne Zusatzschulungen zurechtfinden.
Im Rollout regelmäßig prüfen, ob der Bereich wirklich für die richtigen Nutzer sichtbar und erreichbar ist.
Tiefer einsteigen

Entwickler Info

Eine Action (skip_time_fields) mit INVERTED LOGIC: Permission entzieht einen Validierungs-Constraint statt eine Action zu aktivieren. Trigger-enforced + UI-Hook.

Entwickler-Info aufklappen (1)

⚠ KRITISCHINVERTED LOGIC + Trigger-enforced

Der Trigger check_hours_time_fields() (squash:3512-3528) feuert BEFORE INSERT/UPDATE auf hours: WENN User skip_time_fields hat, überspringe die Pflicht-Validierung. WENN nicht, raise EXCEPTION wenn start_time oder end_time NULL. Die Permission ENTZIEHT einen Validierungs-Constraint, statt eine Action zu aktivieren — INVERTED LOGIC. Live-Preview-Hinweis: "Diese Permission erlaubt es, Stunden ohne Zeitstempel zu erfassen — z.B. Tagessummen statt von-bis." Plus UI-Hook in pages/hours.tsx:125 für Conditional-Render der Zeitfelder.

  • supabase/migrations/20251210234001_squash_baseline.sql:3512-3528
  • pages/hours.tsx:125