docs: ADR-0012 Gegenlese-Korrekturen

- Anführungszeichen-Inkonsistenz behoben (gerade statt „..." an einer Stelle)
- Entscheidungs-Absatz zu Gruppen verweist jetzt vorwärts auf den
  Self-Service-Nachtrag, statt für sich allein veraltet zu wirken

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
Thomas Stallinger 2026-08-12 21:14:38 +02:00
parent a8e67b0c96
commit 502a25e4f6

View File

@ -12,7 +12,7 @@ In der Diskussion kristallisierten sich zwei fachlich unterschiedliche Gruppieru
1. **Organisatorische Verortung** (z. B. „Gebäude A" → „Klasse 5a"): jedes Gerät gehört zu genau einem Ort, Orte können ineinander verschachtelt sein, und Konfiguration soll von einem allgemeineren zu einem spezifischeren Ort vererbt werden können — klassische OU-Semantik.
2. **Querschnitts-Zuordnung** (z. B. „Lehrer", „Schulleitung"): ein Gerät (bzw. dessen Nutzer:in) kann mehreren solcher Zuordnungen gleichzeitig angehören, die Zuordnungen selbst sind nicht hierarchisch.
Beide Bedürfnisse mit einem einzigen, verschachtelbaren Gruppen-Konzept mit Mehrfachmitgliedschaft abzudecken, hätte bedeutet, dass die "zutreffenden Gruppen" eines Geräts keine einzelne Vorfahrenkette mehr sind, sondern die Vereinigung mehrerer, unabhängiger Vorfahrenpfade — mit entsprechend unklarer Konfliktauflösung selbst für den einfachen, hierarchischen Fall. Die beiden Bedürfnisse wurden deshalb bewusst als zwei getrennte Konzepte modelliert.
Beide Bedürfnisse mit einem einzigen, verschachtelbaren Gruppen-Konzept mit Mehrfachmitgliedschaft abzudecken, hätte bedeutet, dass die zutreffenden Gruppen" eines Geräts keine einzelne Vorfahrenkette mehr sind, sondern die Vereinigung mehrerer, unabhängiger Vorfahrenpfade — mit entsprechend unklarer Konfliktauflösung selbst für den einfachen, hierarchischen Fall. Die beiden Bedürfnisse wurden deshalb bewusst als zwei getrennte Konzepte modelliert.
## Entscheidung
@ -22,7 +22,7 @@ Jede Organisation besitzt automatisch eine geschützte Standard-OE **„Neue Ger
Organisationseinheiten sind Self-Service durch die Kund:in selbst verwaltbar (Kundenportal, `/struktur`) — anders als bei Bereitstellungsvorlagen (installationszeitlich, technisch) ist die OE-Struktur eine rein organisatorische Entscheidung, die die Kund:in selbst am besten kennt.
**Gruppen** sind dagegen bewusst flach (keine Verschachtelung) — ein Gerät kann **mehreren Gruppen gleichzeitig** angehören. Gruppen sind in dieser ersten Ausbaustufe nur intern verwaltbar (`/admin/kunden/{id}`), nicht Self-Service: bei der aktuellen, kleinen Kundenzahl sind die Bedürfnisse dem Betreiber bekannt genug, um sie direkt zu pflegen; künftige, heterogenere Kundschaft (KMUs) wird das wahrscheinlich einmal brauchen. Backend-seitig ist die Gruppen-API identisch zur OE-API aufgebaut (gleiche Endpunkt-Struktur für Merkmal-Overrides), sodass Self-Service später ohne Datenmodell-Umbau nachgezogen werden kann — nur die Kundenportal-Routen fehlen dafür noch.
**Gruppen** sind dagegen bewusst flach (keine Verschachtelung) — ein Gerät kann **mehreren Gruppen gleichzeitig** angehören. Gruppen waren in dieser ersten Ausbaustufe zunächst nur intern verwaltbar (`/admin/kunden/{id}`), nicht Self-Service (siehe Nachtrag unten, noch am selben Tag revidiert): bei der aktuellen, kleinen Kundenzahl sind die Bedürfnisse dem Betreiber bekannt genug, um sie direkt zu pflegen; künftige, heterogenere Kundschaft (KMUs) wird das wahrscheinlich einmal brauchen. Backend-seitig ist die Gruppen-API identisch zur OE-API aufgebaut (gleiche Endpunkt-Struktur für Merkmal-Overrides), sodass Self-Service später ohne Datenmodell-Umbau nachgezogen werden kann — nur die Kundenportal-Routen fehlten dafür noch.
**Konfigurationsvererbung:** Sowohl OEs als auch Gruppen können — wie ein Gerät selbst über `device_merkmale` (ADR-0010) — einzelne katalogfähige Merkmale explizit auf `aktiv` oder `inaktiv` setzen (`oe_merkmale`, `gruppen_merkmale`; jeweils sparsam, nur bei tatsächlich abweichender Meinung eine Zeile). Die Auflösungsreihenfolge für ein Gerät ist: