ADR-0057: Field form groups (web layout)

Status: accepted
Datum: 2026-09-08
Phase: Web Schema-CMS
Bezug: ADR-0033, ADR-0045, ADR-0046

Kontext

Felder einer Entität wurden als flache Liste gezeigt. Formulare brauchten visuelle Abschnitte (z. B. „Adresse“), ohne eine neue Entitätsart, QGIS-Gruppe oder Geometrie. Entity-group und Layer-geom_kind=bundle lösen andere Probleme.

Entscheidung

Katalog-Tabelle field_form_groups (plus Checkout-Overlay): kind_code, code, label, sort_order, schema_code. Nur Layout — kein field_type, keine Records, kein QGIS-Mapping.
field_definitions.form_group_code optional, FK auf die Gruppe derselben Kind (ON DELETE SET NULL).
API: GET/POST /entity-kinds/{code}/form-groups, PUT/DELETE …/form-groups/{groupCode}; Fields In/Out tragen form_group_code.
Web-UI: Felder als dynamische Tabelle (Pager, Sort/Filter); Formulargruppen pflegen und im Feld-Dialog zuweisen; Datensatz-Formulare als Fieldsets. Kein Einfluss auf QGIS-Attribute-Formulare.

Gate	Recommendation	Why it fits here	Rejected alternative and why
Modell	eigene Katalogtabelle	klar getrennt von Entity-`group` und Layer-Bündel	Feldtyp „section“ — würde Records/QGIS verwirren
Scope	nur Web	QGIS-Formulare bleiben unverändert	QGIS-Form-Mapping — großer Scope ohne Bedarf
Löschen	SET NULL	Feldwerte bleiben, Layout fällt zurück	Cascade-Delete der Felder — zu destruktiv

Begründung

Layout-Abschnitte gehören zum Web-Formularvertrag, nicht zur Domain-Hierarchie. Eine dünne Katalog-Entity hält Checkout und Vererbung einfach.

Folgen

Alembic public 0039_field_form_groups / Tenant 0024_field_form_groups.
UI: Formulargruppen-Toolbar, Felder-Tabelle, Record-Fieldsets.
Glossar: Formulargruppe ≠ Gruppe ≠ Layer-Bündel.