Wofür das Modul gedacht ist
Benutzerdefinierte Felder ist Teil des aktiven Modul-Katalogs und deckt einen klaren Ausschnitt des Produktalltags ab.
Zusatzfelder für Tabellen und Formulare tenantweit oder pro Projekt definieren. Im tenantweiten Kontext sorgt der Bereich dafür, dass wiederkehrende Entscheidungen, Stammdaten oder Übersichten nicht in Nebensysteme ausweichen müssen.
Benutzerdefinierte Felder 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.
Projekt-Infos
Projekt-Infos ergänzt Benutzerdefinierte Felder, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.
DetailsLV-Positionen
LV-Positionen ergänzt Benutzerdefinierte Felder, weil beide Bereiche im Alltag direkt aufeinander aufbauen oder dieselben Verantwortlichen berühren.
DetailsRechnungsstellung
Rechnungsstellung ergänzt Benutzerdefinierte Felder, 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 mit eleganter _all/scoped-Trennung via conditional RLS — eine Policy entscheidet via project_id-Branching, ob _all oder scoped greift. Plus API-Pre-Checks mit Bypass-Pfad.
Entwickler-Info aufklappen (2)
Conditional RLS-Verdrahtung
Drei RLS-Policies (insert/update/delete_own_fields auf custom_field_definitions) haben ein verschachteltes OR: WENN project_id IS NULL prüfe manage_custom_fields_all, sonst manage_custom_fields. So entscheidet eine einzige Policy elegant via project_id-Wert, welche Permission greift. Ungewöhnlich kompakte Verdrahtung — andere Module haben für sowas zwei separate Policies.
supabase/migrations/20251210234001_squash_baseline.sql:23702 (delete)supabase/migrations/20251210234001_squash_baseline.sql:24435 (insert)supabase/migrations/20251210234001_squash_baseline.sql:26195 (update)
Bypass-Pfad: _all öffnet auch project-scoped
In projects/[id]/custom-fields/index.ts:138 ist manage_custom_fields_all eine OR-Alternative zu manage_custom_fields. Wer _all hat, kann auch project-scoped Custom-Fields verwalten — ohne explizite scoped-Permission. Live-Preview muss beim Schließen von _all anzeigen: "Wer manage_custom_fields_all schließt, verliert auch den Bypass-Pfad zu project-scoped Custom-Fields."
pages/api/projects/[id]/custom-fields/index.ts:132-139