From 502a25e4f692bb8a24f96b4aa207cce360e9568e Mon Sep 17 00:00:00 2001 From: Thomas Stallinger Date: Wed, 12 Aug 2026 21:14:38 +0200 Subject: [PATCH] docs: ADR-0012 Gegenlese-Korrekturen MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - 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 --- ...-organisationseinheiten-gruppen-konfigurationsvererbung.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/adr/0012-organisationseinheiten-gruppen-konfigurationsvererbung.md b/adr/0012-organisationseinheiten-gruppen-konfigurationsvererbung.md index 371d6f5..ceee648 100644 --- a/adr/0012-organisationseinheiten-gruppen-konfigurationsvererbung.md +++ b/adr/0012-organisationseinheiten-gruppen-konfigurationsvererbung.md @@ -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: