Wofür das Modul gedacht ist
Änderungsprotokoll ist Teil des aktiven Modul-Katalogs und deckt einen klaren Ausschnitt des Produktalltags ab.
Wer was wann geändert hat nachvollziehen. Im tenantweiten Kontext sorgt der Bereich dafür, dass wiederkehrende Entscheidungen, Stammdaten oder Übersichten nicht in Nebensysteme ausweichen müssen.
Änderungsprotokoll 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.
Tenant sauber aufsetzen
Das Modul hilft dabei, organisatorische Regeln und Stammdaten an einer kontrollierten Stelle zu pflegen.
Verantwortung eingrenzen
Governance-Bereiche sollten nur wenige Personen pflegen, damit die Struktur stabil bleibt.
Rollouts belastbar machen
Eine klare Administrationsstruktur vereinfacht Onboarding, Rechtestruktur und spätere Produkterweiterungen.
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.
Administration
Administration ergänzt Änderungsprotokoll, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.
DetailsBerechtigungen
Berechtigungen ergänzt Änderungsprotokoll, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.
DetailsBautagebuch
Bautagebuch ergänzt Änderungsprotokoll, 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
Zwei Permissions (view_all + view_own) mit echter Asymmetrie: view_all gates 2 Tabellen (activity_logs + audit_log), view_own gates NUR activity_logs. Drei-Schichten-Enforcement für view_all (API + zwei RLS-Pfade). admin_logging ist die EFFEKTIVE Permission für die System-Logs-Page — admin_logs.view_logs ist tot.
Entwickler-Info aufklappen (3)
⚠ KRITISCHAsymmetrie: view_own greift NICHT auf audit_log
Die RLS-Policy activity_logs_select_own filtert auf tenant + employee_id=current + Permission. ABER: audit_log hat KEINE _select_own-Policy. Wer view_own hat, sieht NIE audit_log-Einträge — auch nicht die eigenen. Wer alle eigenen Aktivitäten sehen will, braucht view_all (was dann aber auch fremde sieht). Live-Preview sollte beim Öffnen von view_own warnen: "Diese Permission deckt nur in-app-Änderungen, keine DB-Trigger-Logs."
supabase/migrations/20251210234001_squash_baseline.sql:23373 (activity_logs_select_own)supabase/migrations/20251210234001_squash_baseline.sql:25902 (audit_log RLS — NUR view_all)
⚠ KRITISCHDrei-Schichten-Enforcement für view_all
view_all wird an drei Stellen geprüft: (1) API /api/audit-log:25 als primary gate mit klarem 403-String, (2) RLS auf activity_logs_select_all, (3) RLS auf audit_log via _audit_log_authorized_tenant_id() Wrapper-Funktion. Die Wrapper-Funktion ist eine Performance-Optimierung — sie ruft can_perform_action EINMAL pro Statement statt pro Row.
pages/api/audit-log/index.ts:25supabase/migrations/20251210234001_squash_baseline.sql:367-396 (Wrapper-Funktion)
⚠ KRITISCHadmin_logs.view_logs ist tot — diese Permission ist die echte
In dim_modules existiert ein zweites Modul admin_logs mit der Permission view_logs. Dieses Modul ist deaktiviert (is_active=false). Die System-Logs-Page (pages/admin/logs.tsx:116) nutzt hasAccess('admin_logging'), nicht admin_logs. admin_logs.view_logs ist ein vestigial Toggle aus dem alten Logging-Schema und sollte als DEAD markiert werden.
pages/admin/logs.tsx:116supabase/migrations/20251211000000_seed_dim_modules.sql:24 (is_active=false)