struct-i-vio
StartseiteDokumentationModuleBautagebuch
Projekte & Koordination · Projektmodul

Bautagebuch: wofür der Bereich im Projektkontext gedacht ist.

Tägliche Baustellendokumentation mit Wetter, Anwesenheit, Fortschritt, Prüfungen und Anlagen. Das Modul erscheint innerhalb eines einzelnen Projekts und wirkt damit unmittelbar im Projektkontext.

  • Bautagebuch erklärt kompakt, wofür der Bereich gedacht ist und wann er im Arbeitsalltag relevant wird.
  • Der Bereich spielt in der Praxis besonders mit Terminplan und Dokumente zusammen.
  • Nutzen, Sichtbarkeit und Verantwortlichkeit ergeben sich hier stark aus dem Projektkontext.
Zur ModulübersichtRollen & Berechtigungen lesen
Direkt zu
Modulzweck

Wofür das Modul gedacht ist

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

Tägliche Baustellendokumentation mit Wetter, Anwesenheit, Fortschritt, Prüfungen und Anlagen. Im Projektkontext bedeutet das, dass der Bereich nicht isoliert funktioniert, sondern direkt an Team, Status und weitere Projektbereiche anknüpft.

Bautagebuch 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 erscheint innerhalb eines einzelnen Projekts und wirkt damit unmittelbar im Projektkontext.
Praxisbezug

Typische Einsatzfälle

Diese Situationen zeigen, wann der Bereich in einem sauberen Rollout oder im laufenden Betrieb konkret Mehrwert liefert.

Baustellentage dokumentieren

Wetter, Ereignisse, Personal und Fortschritt können tagesgenau im Projekt dokumentiert werden.

Prüfungen nachvollziehbar halten

Besondere Vorkommnisse, Mangelbilder oder Nachweise bleiben mit Datum und Projektkontext nachvollziehbar verankert.

Projektwissen laufend sichern

Das Modul schützt operatives Wissen davor, in Chats, Papiernotizen oder separaten Tools zu verschwinden.

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.

Projektmodul

Terminplan

Terminplan ergänzt Bautagebuch, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.

Details
Projektmodul

Dokumente

Dokumente ergänzt Bautagebuch, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.

Details
Projektmodul

Team

Team ergänzt Bautagebuch, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.

Details
Sichtbarkeit

Berechtigungen und Sichtbarkeit

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

Die Sichtbarkeit orientiert sich in der Regel am Projektkontext, an Projektmitgliedschaft und an projektbezogenen Zusatzrollen.
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.

Projektmodule zuerst für die tägliche Zusammenarbeit optimieren und später mit Reporting- oder Spezialfunktionen ausbauen.
Den Bereich immer mit Projekt-Infos, Team und Dokumentation verzahnen, damit keine Schattenprozesse entstehen.
Leitung und Projektteam früh sauber abbilden, damit die Sichtbarkeit im Alltag belastbar bleibt.
Tiefer einsteigen

Entwickler Info

Sehr ungewöhnliches Modul: 4 von 6 _all-Permissions sind TRULY UNBOUND (view, manage, finalize, delete jeweils _all). Nur reopen_entry_all und export_bautagebuch_all sind sauber verdrahtet. Konsequenz: für die meisten globalen Bautagebuch-Aktionen gibt es keinen Bypass — User braucht in jedem Projekt die scoped-Permission separat.

Entwickler-Info aufklappen (4)

⚠ KRITISCH4 TRULY UNBOUND _all-Toggles: view, manage, finalize, delete (jeweils _all)

view_bautagebuch_all, manage_entries_all, finalize_entry_all und delete_entry_all sind in dim_modules definiert, aber NIRGENDS enforced — kein Code-Callsite, kein RPC, keine RLS, keine View. Praktische Folge: ein User, der das Bautagebuch projekt-übergreifend verwalten soll, muss in jedem einzelnen Projekt Mitglied sein und die scoped-Permission haben — oder Tenant-Admin (Level 0) sein. Globale Bautagebuch-Sicht ist nicht delegierbar.

  • scripts/probes/probe-project-bautagebuch-module.js
  • Vergleich: nur reopen_entry_all (reopen.ts:74) und export_bautagebuch_all (export.ts:68) sind sauber verdrahtet

view_bautagebuch gates 8 Tabellen, manage_entries gates 14 Mutation-Policies

view_bautagebuch ist die zentrale SELECT-Permission für bautagebuch_entries plus 7 Sub-Tabellen (activities, attendance, equipment, incidents, inspections, visitors, attachments) und _revisions/_reopen_events/_sync_conflicts. manage_entries gates ALLE Mutations dieser 8 Tabellen. Eine Permission regiert die gesamte Datenstruktur — keine Granulariät zwischen Aktivitäten / Vorfällen / etc.

  • RLS: 30+ Policies auf bautagebuch_*-Tabellen

Status-State-Machine: draft → finalized → reopened

manage_entries und delete_entry greifen NUR auf status=draft Einträge — finalisierte Einträge sind unveränderlich. finalize_entry erlaubt den Übergang draft→finalized (RLS-WITH_CHECK). reopen_entry kehrt das um (RPC reopen_bautagebuch_entry). Audit-Log in bautagebuch_reopen_events.

  • RLS: bautagebuch_entries_update mit (status<>finalized OR finalize_entry)
  • RPC: reopen_bautagebuch_entry

Stage-1-Couplings (bestehend)

manage_entries und view_bautagebuch brauchen projects.view_all_projects (Endpoint lädt Zielprojekt zur Validierung).

  • lib/permission-dependencies.ts
Vorherige Seite

Module

Der öffentliche Modulkatalog von struct-i-vio mit einer eigenen Docs-Seite für jeden aktiven Produktbaustein.

Jetzt loslegen

struct-i-vio im eigenen Setup testen

Wenn Sie den Einstieg konkret planen, können Sie direkt einen eigenen Arbeitsbereich anlegen.