Schule einrichten: Klassen nach Muster B

Kurzfassung

Eine Schule, die Prilog produktiv einsetzt, will drei Dinge gleichzeitig: Schüler-Lehrer-Kommunikation, Eltern-Lehrer-Kommunikation und gelegentlich einen Raum, in dem alle zusammen etwas besprechen. Muster B löst das mit einem Klassen-Container und thematischen Unter-Räumen, statt zwei parallele Strukturen aufzubauen. Prilog legt eine komplette Klasse samt Policies mit einem einzigen Klick im Portal an.

Das Problem

Stell dir eine ganz normale Klasse vor: 26 Schüler, 2 Klassenleiter, ca. 50 Eltern. In Prilog willst du dafür Kommunikation auf drei Achsen:

Gespräche	Wer spricht?	Beispiel
Unterricht	Lehrkraft ↔ Schüler	„Hausaufgabe ist Seite 42", Klassen-Chat
Organisation	Lehrkraft ↔ Eltern	Elternabend, Zeugnisfrage, Entschuldigung
Gemeinsam	Alle drei	Klassenfahrt, Krisenfall, Sommerfest

Wichtig: Schüler sollen nicht lesen, was Lehrer und Eltern über sie besprechen. Eltern sollen nicht im Schüler-Chat mitlesen. Das ist keine Willkür, sondern rechtlich geboten (Datenschutz, Aufsichtspflicht, pädagogische Vertraulichkeit).

Die falschen Antworten

Muster A — Zwei parallele Klassen-Strukturen (vermeiden)

Klassen/
├── Klasse 7a              (Lehrer + Schüler)
├── Klasse 7a-Eltern       (Lehrer + Eltern)
├── Klasse 7b              ...
└── Klasse 7b-Eltern       ...

Das ist der Reflex. Und die schlechteste Lösung:

• Jeder Lehrer ist in der doppelten Anzahl Spaces
• Organisations-Änderungen müssen immer zweimal nachgezogen werden
• Lehrer verwechseln die Räume und schreiben Schüler-Infos versehentlich in den Eltern-Raum
• Eltern mit mehreren Kindern haben doppelt so viele Räume wie nötig

Das willst du nicht.

Die richtige Antwort: Muster B

Ein Klassen-Container pro Klasse, darunter zwei thematische Unter-Räume mit unterschiedlichen Zugangsregeln:

Schule/                                   [Schulleitung → Owner]
└── Klassen/                              [Lehrkraft → Admin, vererbt]
    └── Klasse 7a/                        (Container, kein Chat)
        ├── 7a Unterricht                 [Lehrkraft → Admin, Schüler → Member]
        └── 7a Eltern                     [Lehrkraft → Admin, Elternteil → Member]

Was hier passiert:

• Klasse 7a ist nur ein Ordner — kein Chat findet dort statt. Alle drei Gruppen (Lehrer, Schüler, Eltern) können ihn als Space sehen, weil „die Klasse existiert" keine Geheimnis-Information ist.
• 7a Unterricht: Das „Erlaubte Benutzertypen"-Gate blockiert aktiv Eltern, wenn sie aus Versehen hinzugefügt werden. Das Backend lehnt Einladungen, Zugangsanträge und Admin-Adds mit einer klaren Fehlermeldung ab. Schüler schreiben hier ohne Eltern-Mitleser.
• 7a Eltern: Gleicher Mechanismus umgekehrt — Schüler sind nicht in der Policy-Liste, kommen nicht rein. Lehrer-Eltern-Kommunikation ist geschützt.

Warum das elegant ist

1. Lehrer sind in genau einem Kontext („Klasse 7a") und sehen beide Unter-Räume auf einmal im Matrix-Client als verschachtelten Baum. Keine Verwechslungen.
2. Schüler sehen nur ihre Räume — in „Klasse 7a" taucht für sie nur Unterricht auf. Eltern ist für sie technisch unsichtbar.
3. Eltern sehen nur ihre Räume — in „Klasse 7a" nur Eltern. Unterricht ist unsichtbar.
4. Vererbung tut die Arbeit: Die Policy „Lehrkraft → Admin" am Parent „Klassen" greift automatisch auf alle Kinder. Du setzt sie einmal.
5. Eltern mit mehreren Kindern werden einfach Mitglied in mehreren „7a Eltern", „4b Eltern" — das rendert im Matrix-Client als verschachtelter Baum natürlich.

Ausflüge, Projekte, Klassenfahrten?

Der gemeinsame Raum für alle drei (Lehrer + Schüler + Eltern) ist kein Teil der Standard-Vorlage. Er ist im Alltag selten genug, dass du ihn bei Bedarf manuell nachlegst:

• Klassenfahrt steht an → Du legst „7a Klassenfahrt 2027" als drittes Kind unter „Klasse 7a" an, setzt drei Policies (Lehrkraft → Admin, Schüler → Member, Elternteil → Member), fertig. Dauert 2 Minuten.
• Sommerfest-Vorbereitung → dasselbe Muster, ein neuer Unter-Raum.
• Krisenfall → das ist eher ein Fall für die Krisen-Management-Funktion, kein Klassen-Raum.

Wir halten die Standard-Vorlage bewusst schlank, damit im Normalfall keine unbenutzte Ebene herumsteht.

Erst-Einrichtung: Schul-Starter-Paket

Bevor du einzelne Klassen anlegst, brauchst du die Grundstruktur deiner Schule — Schulleitung, Kollegium, Verwaltung, Klassen-Container, Eltern-Info. Statt das alles einzeln zu bauen, gibt es dafür Schul-Starter-Pakete.

Im Portal unter Benutzer → Spaces findest du den Button „Schul-Struktur einrichten" (Sparkles-Icon). Er bietet zwei Pakete:

Paket	Spaces	Für
Kleine Schule (bis 400)	7	Schulleitung, Kollegium, Verwaltung, Klassen-Container, Eltern-Info, IT & Support
Große Schule (bis 1000)	9	Wie oben + Fachbereiche-Container + Projekte-Container

Du gibst den Namen deiner Schule ein, wählst ein Paket, und Prilog legt die gesamte Struktur in einem Schritt an — inklusive Matrix-Räume und Benutzertyp-Policies (Schulleitung → Owner, Lehrkraft → Admin/Member, Verwaltung → Member, je nach Space).

Der Klassen-Container ist dabei absichtlich leer: er dient als Sammel-Knoten, unter dem du danach die einzelnen Klassen über den Button „Neue Klasse anlegen" ergänzt. So bekommt jede Klasse ihre Muster-B-Unter-Räume (Unterricht + Eltern) mit den richtigen Zugangsregeln.

Empfohlene Reihenfolge beim Erst-Setup

1. Benutzertypen anlegen (Lehrkraft, Schüler:in, Elternteil, Verwaltung, Schulleitung)
2. Schul-Struktur einrichten (Starter-Paket)
3. Klassen einzeln anlegen (über „Neue Klasse anlegen" unter dem Klassen-Container)
4. Benutzer anlegen und Spaces zuweisen

So legst du eine Klasse an

Prilog bietet dafür einen Ein-Klick-Dialog, der alle Räume und Policies in einem Schritt erzeugt.

Voraussetzung: Benutzertypen müssen existieren

Das System funktioniert nur, wenn in deinem Tenant die drei grundlegenden Benutzertypen angelegt sind — typischerweise mit diesen Schlüsseln:

• lehrkraft / lehrer / teacher — Lehrkraft
• schueler_in / schueler / student — Schüler:in
• elternteil / eltern / parent — Elternteil

Die genaue Schreibweise ist egal — Prilog matcht jede der gängigen Varianten automatisch. Wenn deine Schule die Typen anders nennt (z.B. „Pädagoge" statt „Lehrer"), siehst du im Anlege-Dialog eine Warnung und kannst die Policy nachträglich manuell im Panel „Erlaubte Benutzertypen" setzen.

Siehe Benutzertypen für die Einrichtung.

Klasse anlegen — Schritt für Schritt

1. Benutzer → Spaces öffnen
2. (Optional, aber empfohlen) Einen Container-Space „Klassen" anlegen, falls noch nicht vorhanden. Dort kannst du später eine Vererbungs-Policy setzen wie „Lehrkraft → Admin", die automatisch auf alle Unter-Klassen durchschlägt.
3. In der Spaces-Ansicht auf den prominenten Button „Neue Klasse anlegen" klicken (mit dem Graduation-Cap-Icon).
4. Im Dialog:
   • Klassen-Name eingeben, z.B. „Klasse 7a"
   • Übergeordneter Space auswählen — idealerweise „Klassen"
   • Der Vorschau-Block zeigt dir sofort, was gleich entsteht:

     📁 Klasse 7a (Container)
       └── 💬 Klasse 7a Unterricht
               Zugelassene Benutzertypen: lehrkraft → ADMIN, schueler_in → MEMBER
       └── 💬 Klasse 7a Eltern
               Zugelassene Benutzertypen: lehrkraft → ADMIN, elternteil → MEMBER

5. Auf „Klasse anlegen" klicken.

Prilog legt jetzt in einem Rutsch an:

• Parent-Container „Klasse 7a" (mit Matrix-Raum, kein Chat)
• Kind „Klasse 7a Unterricht" (mit Matrix-Raum, Policies gesetzt)
• Kind „Klasse 7a Eltern" (mit Matrix-Raum, Policies gesetzt)
• Alle Matrix-Hierarchie-Relationen (m.space.child / m.space.parent), damit der Baum im Client korrekt angezeigt wird

Der Dialog schließt sich, die neue Klasse ist in der Tree-Ansicht selektiert. Fertig.

Wenn der Dialog Warnungen zeigt

Wenn die Feedback-Meldung „Hinweise: ..." enthält, bedeutet das meistens, dass mindestens ein Benutzertyp im Tenant nicht mit einem der erwarteten Schlüssel gefunden wurde. Die Klasse wurde trotzdem angelegt — du musst nur im Panel „Erlaubte Benutzertypen" des betroffenen Unter-Raums die fehlende Policy manuell nachsetzen.

Beispiel-Aufbau einer Schule

Für eine Schule mit ~15 Klassen, Kollegium und Fachbereichen:

Schule/                                   [Schulleitung → Owner, Schulträger → Owner]
├── Klassen/                              [Lehrkraft → Admin vererbt]
│   ├── Klasse 5a/ {Unterricht, Eltern}
│   ├── Klasse 5b/ {Unterricht, Eltern}
│   ├── Klasse 6a/ {Unterricht, Eltern}
│   ├── ...
│   └── Klasse 13/ {Unterricht, Eltern}
├── Kollegium/                            [Lehrkraft → Member]
│   ├── Kollegium Allgemein
│   ├── Fachkonferenz
│   └── Pädagogische Konferenz
├── Fachbereiche/                         [Lehrkraft → Member]
│   ├── Mathematik
│   ├── Deutsch
│   └── ...
├── Schulleitung/                         [Schulleitung → Member]
└── Info für alle Eltern/                 [Lehrkraft → Admin, Elternteil → Member]

Policies musst du an vier Stellen setzen:

1. Schule (Root) — Schulleitung + Schulträger als Owner
2. Klassen — Lehrkraft → Admin (wird an alle 15 Klassen und ihre 30 Unter-Räume vererbt)
3. Kollegium + Fachbereiche — Lehrkraft → Member (nur Lehrer-Zugang)
4. Info für alle Eltern — Lehrkraft + Elternteil (schulweites Eltern-Brett)

15 Klassen × 2 Unter-Räume = 30 Räume werden automatisch durch zwei Policy-Einträge in „Klassen" vollständig reguliert. Das ist der Skalen-Effekt, den die Vererbung liefert.

Der einmalige Einrichtungs-Aufwand

Mit dem „Neue Klasse anlegen"-Dialog im Portal:

• 15 Klassen × 10 Sekunden pro Klick = 2.5 Minuten für alle Klassen-Strukturen
• • Policies an den 4 Wurzel-Spaces setzen = weitere ~5 Minuten
• • Mitglieder zuweisen (Lehrer + Schüler + Eltern) = abhängig von Quelle (Bulk-Import vs. manuell)

Die Rechte-Struktur selbst ist in unter 10 Minuten komplett. Das Zuweisen der Personen ist danach der zeitintensive Teil, aber dafür gibt es Bulk-Import und das automatische Greifen der Gate-Policies.

Wann Muster B nicht passt

Muster B ist für Schulen mit klar getrennten Rollen gedacht (Lehrer / Schüler / Eltern). Für andere Organisationen ist es ggf. zu viel:

• Mini-Schule mit 20 Personen: Weniger Trennung nötig, ein Raum pro Klasse reicht. Lehrer können Eltern ggf. direkt per DM ansprechen.
• Hochschule: Andere Rollen-Logik (Dozent, Studierende, Tutoren), Muster-B-Vorlage passt nicht direkt — eigene Template-Variante wäre sinnvoll.
• Verein / Betrieb: Dort gibt es oft keine „Eltern"-Schicht, also nur ein Unter-Raum pro Gruppe, nicht zwei.

Für diese Fälle legst du Spaces weiter wie bisher manuell an (siehe Spaces, Benutzer & Rollen). Die Template-Funktion kann später für jede Organisation eigene Vorlagen bekommen — das ist ein Feature für zukünftige Versionen.

Zusammenfassung

• Zwei Unter-Räume pro Klasse, nicht doppelte Klassen-Struktur.
• Ein-Klick-Anlage via Portal-Dialog „Neue Klasse anlegen".
• Vererbung an den Wurzel-Spaces erledigt die Rechte-Arbeit für dich.
• Ausflug-/Projekt-Räume legst du bei Bedarf manuell nach — nicht im Standard.
• Sicherheit durch Gate: Falsche Benutzertypen werden aktiv blockiert, nicht nur ausgeblendet.

Muster B ist die empfohlene Referenz-Architektur für Schulen, die Prilog produktiv einsetzen, und wird von den aktuellen Bordmitteln vollständig unterstützt.

Marketing-Aussagen für Schulträger

Wenn du einer Schule, einem Schulträger oder einem Datenschutzbeauftragten Prilog vorstellst, sind folgende Formulierungen sachlich korrekt und im Code hinterlegt:

• „Prilog erlaubt eine datenschutzkonforme Trennung zwischen Schüler- und Elternkommunikation in derselben Klasse, ohne doppelte Space-Strukturen pflegen zu müssen."
• „Eine neue Klasse mit allen Zugangsregeln entsteht in Prilog per Ein-Klick-Dialog — keine manuelle Rechte-Konfiguration, keine Fehlerquelle."
• „Versuche, einen Benutzer in einen Raum zu laden, der nicht seinem Benutzertyp entspricht, werden vom Backend aktiv blockiert. Der Fehler taucht sofort mit einer klaren Meldung auf, nicht erst nach einem Datenschutz-Zwischenfall."
• „Die Policy-Regeln werden einmalig am Wurzel-Space (z. B. ‚Klassen') gesetzt und gelten automatisch für alle unter- und nachgeordneten Klassen durch Vererbung. Der Einrichtungs-Aufwand skaliert nicht mit der Schulgröße."