Rechte- und Rollenkonzept

Die Future-Box steuert den Zugriff über sechs Rollen mit jeweils unterschiedlichen Berechtigungen. Dieser Abschnitt enthält die vollständige Rollen- und Permission-Matrix sowie eine Erläuterung jeder einzelnen Berechtigung.

Überblick

Das Berechtigungsmodell basiert auf der Bibliothek Spatie Laravel Permission. Drei Bausteine arbeiten zusammen:

Rolle — eine benannte Sammlung von Permissions, einer Person zugewiesen.
Permission — ein einzelnes, fein granuliertes Recht (z. B. edit_user, use_portfolio).
Policy — modellbezogene Zugriffsregeln, die zusätzlich zu Permissions greifen (z. B. „nur eigene Memos editierbar“).

Jede angemeldete Person hat genau eine Rolle. Permissions ergeben sich aus dieser Rolle. Policies prüfen darüber hinaus für einzelne Datensätze, ob die Aktion zulässig ist.

Die sechs Rollen

Rolle (UI-Standardname)	Code-Schlüssel	DB-Name	Renaming-Schlüssel	Kurzbeschreibung
🛡️ Superadmin	`superadmin`	„Superadmin“	–	Technische Höchstrolle, hat alle Rechte
⚙️ Administrator	`admin`	„Admin“	`role_admin`	Verwaltet Nutzer:innen und Konfiguration der Instanz
👩‍🏫 Lehrperson	`teacher`	„Lehrperson“	`role_teacher`	Unterstützt Lernende; sieht Dashboard, kann Aufgaben stellen, Feedback mit Datei-Anhang geben
🎓 Auszubildender	`user`	„Azubi“	`role_apprentice`	Standardrolle für Lernende; kann Stacks und Memos pflegen
🛠️ Ausbilder	`trainer`	„Ausbilder“	`role_trainer`	Sieht Trainer-Dashboard mit zugeordneten Auszubildenden, gibt Berichtshefte frei
🏛️ Kammer-Admin	`chamberadmin`	„Kammer-Admin“	`role_chamber`	Sieht Kammer-Dashboard, prüft eingereichte Berichtshefte, verwaltet Kammer-User

⚠️ Hinweis: Die UI-Namen lassen sich über die Renaming-Funktion anpassen (z. B. „Auszubildender“ → „Lernende:r“ oder „Schüler:in“). Die Code-Schlüssel und DB-Namen bleiben unverändert und sind die technische Grundlage für alle Berechtigungs-Prüfungen.

Permission-Matrix

Die folgende Tabelle zeigt, welche Permission jede Rolle in der Standardkonfiguration besitzt:

Permission	🛡️ Superadmin	⚙️ Admin	👩‍🏫 Lehrperson	🎓 Auszubildender	🏛️ Kammer-Admin	🛠️ Ausbilder
`view_administration`	✅	✅	–	–	–	–
`view_configuration`	✅	–	–	–	–	–
`edit_all_user`	✅	–	–	–	–	–
`edit_user`	✅	✅	–	–	✅	–
`edit_chamber_users`	–	–	–	–	✅	–
`edit_config`	✅	–	–	–	–	–
`edit_settings`	✅	–	–	–	–	–
`edit_renamings`	✅	–	–	–	–	–
`edit_all_templates`	✅	–	–	–	–	–
`edit_jobs`	✅	–	–	–	✅	✅
`edit_task_description`	✅	✅	✅	–	–	✅
`edit_tasks`	✅	✅	✅	–	–	–
`feedback_upload_media`	✅	✅	✅	–	–	–
`view_dashboard`	✅	✅	✅	–	–	–
`use_portfolio`	✅	✅	✅	✅	✅	✅
`view_trainer`	–	–	–	–	–	✅
`view_chamber_admin`	–	–	–	–	✅	–

💡 Lese-Hinweis: Die ✅ in der Matrix entstehen durch eine additive Vererbung: Superadmin enthält Admin enthält Lehrperson enthält Auszubildender. Kammer-Admin und Ausbilder haben eigene Permission-Sets, die nicht automatisch in die anderen Rollen einfließen.

Was bewirkt jede Permission?

Verwaltungs-Permissions

Permission	Wirkung
`view_administration`	Zugang zum `/administration`-Bereich (Mittel: `IsAdmin`-Middleware)
`view_configuration`	Eintrag „System-Konfiguration“ in der Footer-Navigation
`edit_all_user`	Volle User-Administration (auch über Tenant-Grenzen hinweg, technisch reserviert für Superadmin)
`edit_user`	Nutzer:innen anlegen, bearbeiten, löschen, importieren (Benutzerverwaltung)
`edit_chamber_users`	Kammer-spezifische User-Verwaltung (Kammer-Admins, Ausbilder, Auszubildende des Kammer-Bereichs)
`edit_config`	Login-Type, OAuth-Daten, LDAP-Verbindungen ändern
`edit_settings`	Basis-Einstellungen, Profilfelder, Lernort-Typen, Stack-Vorlagen, Berichtsheft-Export-Layout
`edit_renamings`	Begriffe der UI umbenennen (Renaming-Funktion)
`edit_all_templates`	Alle Stack-Vorlagen verwalten
`edit_jobs`	Ausbildungsbetriebe (Code: `Job`) anlegen, bearbeiten, löschen

Inhaltliche Permissions

Permission	Wirkung
`use_portfolio`	Zugang zur Stack-Übersicht und allen Memo-, Tag-, Lernort-, Freigabe- und Export-Funktionen
`edit_task_description`	Im Memo zusätzlich die Felder „Aufgabentitel“ und „Aufgabenbeschreibung“ sichtbar/setzbar
`edit_tasks`	Aufgaben/Lehrelemente bearbeiten (verwandt zu `edit_task_description`)
`feedback_upload_media`	Beim Geben von Feedback in einer Link-Freigabe darf eine Datei angehängt werden
`view_dashboard`	Standard-Dashboard sehen (Standard-Vorraussetzung für alle Inhalte-Pfleger:innen)

Spezialrollen-Permissions

Permission	Wirkung
`view_trainer`	Zugang zum Trainer-Dashboard und den Berichtsheft-Aktionen für Auszubildende
`view_chamber_admin`	Zugang zum Kammer-Dashboard und den Kammer-Admin-Verwaltungs-Routen

Vererbungs-Logik

Die Standard-Permissions werden in der folgenden Reihenfolge aufgebaut (siehe PermissionsTableSeeder):

Superadmin    ⊇  Admin  ⊇  Lehrperson  ⊇  Auszubildender
    │
    └─ +eigene Superadmin-Rechte

Kammer-Admin  und  Ausbilder
    sind eigenständige Sets ohne Vererbung.

Konkret:

Superadmin erhält alle Admin-, Lehrperson- und Auszubildender-Permissions plus eigene Superadmin-Rechte.
Admin erhält Lehrperson- und Auszubildender-Permissions plus eigene Admin-Rechte.
Lehrperson erhält Auszubildender-Permission (use_portfolio) plus eigene Teacher-Rechte.
Auszubildender hat nur use_portfolio.
Kammer-Admin hat ein eigenes Set (view_chamber_admin, use_portfolio, edit_chamber_users, edit_user, edit_jobs).
Ausbilder hat ein eigenes Set (view_trainer, use_portfolio, edit_jobs, edit_task_description).

Policy-Layer (modellbezogene Zugriffsregeln)

Über die rein berechtigungsbasierte Prüfung hinaus arbeiten in der Future-Box Policies für einzelne Modelle. Sie prüfen, ob eine Person eine bestimmte Aktion auf einem bestimmten Datensatz ausführen darf.

Policy	Prüfung
EntryPolicy (Memo)	View/Update/Delete: nur eigener Inhalt; Update/Delete zusätzlich blockiert, wenn Memo aus einer Code-Freigabe stammt mit `can_edit_trainee = false` und Person die Rolle `user` hat
PortfolioPolicy (Stack)	View/Update/Delete: nur eigene Stacks
PublishPolicy (Link-Freigabe)	Update/Delete: nur eigene Freigaben
SharePolicy (Code-Freigabe / Vorlage)	Update/Delete: nur eigene
TagPolicy	View/Update/Delete: nur eigene Tags
LocationPolicy	View/Update/Delete: nur eigene Lernorte

Ein subtiler Schutz für Code-Freigaben

Wenn eine Lehrkraft einen Stack als Vorlage an Lernende verteilt und beim Erstellen das Flag „darf von Auszubildenden bearbeitet werden“ (can_edit_trainee) deaktiviert lässt, dann können die Lernenden die importierten Memos zwar sehen, aber nicht ändern oder löschen. So bleibt die Original-Aufgabenstellung intakt — siehe Stacks.

Spezialfälle

Erste Person wird Superadmin

Beim allerersten Aufsetzen einer Instanz erhält die zuerst registrierte (oder durch LDAP angemeldete) Person automatisch die Rolle Superadmin (User::count() === 0-Check beim Anlegen). Folgende Personen erhalten die Standard-Rolle (user).

⚠️ Empfehlung: Stellen Sie sicher, dass die erste Person in einer neuen Instanz tatsächlich die spätere Administration ist – nicht ein Test-Account.

Default-User

Pro Instanz kann genau ein Account das Flag default = 1 tragen. Dieser Account hat folgende Spezial-Eigenschaften:

Login lokal mit E-Mail + Passwort möglich, auch bei LDAP/Keycloak als globalem Login-Type.
In der Benutzerverwaltung versteckt (vor versehentlicher Löschung geschützt).
Kann das eigene Passwort nicht über das Profil ändern (nur über DB / Admin direkt) — schützt den Notfall-Bypass.

Superadmin-Schutz

Nicht in der Benutzerliste sichtbar (UserController-Filter, Benutzerverwaltung)
Nicht über das Profil löschbar (Profile-Controller-Schutz)
Nur durch tieferen Eingriff (Datenbank, Konsole) entfernbar

Dashboard-Routing

Personen mit view_chamber_admin oder view_trainer werden nach dem Login nicht zur Stack-Übersicht geleitet, sondern in ihr Spezial-Dashboard. Auch wenn sie zusätzlich use_portfolio haben, sehen sie das Standard-Hauptmenü nicht. Siehe Dashboard und Hauptmenü.

Wer darf Rollen vergeben?

Aktion	Erforderlich
Rolle in der allgemeinen Benutzerverwaltung vergeben/ändern	Berechtigung `edit_user` (Standard: Superadmin, Admin, Kammer-Admin)
Kammer-spezifische Rollen vergeben (Kammer-Admin, Ausbilder, Auszubildender)	Berechtigung `edit_chamber_users` (Standard: Kammer-Admin)
Superadmin-Rolle vergeben	technisch nicht über die UI vorgesehen — nur über Konsole/DB

Welche Rolle für welche Personen?

Anhand typischer Einsatzkontexte:

Person	Empfohlene Rolle	Begründung
Schüler:in / Auszubildende:r	🎓 Auszubildender	Standardrolle; alle Inhalts-Funktionen verfügbar
Lehrkraft / Tutor:in	👩‍🏫 Lehrperson	Zusätzlich Aufgaben formulieren, Feedback mit Datei-Anhang
Ausbilder:in (dual)	🛠️ Ausbilder	Trainer-Dashboard, Berichtsheft-Freigabe
Kammer-Verantwortliche:r	🏛️ Kammer-Admin	Kammer-Dashboard, Kammer-Userverwaltung
Schul-/Träger-Verantwortliche:r	⚙️ Administrator	Konfiguration, Nutzerverwaltung der Instanz
Technische:r Verantwortliche:r	🛡️ Superadmin	nur intern, sparsam vergeben

Hinweise & Tipps

Sparsam mit Superadmin: Vergeben Sie diese Rolle nur an wenige technische Verantwortliche. Sie öffnet alle Türen.
Pro Person eine Rolle: Eine Person mit Doppelrolle „Lehrperson + Ausbilder“ lässt sich nur über zwei separate Accounts abbilden, da das System pro Account genau eine Rolle erlaubt.
Rolle wechseln wirkt sofort: Nach Speichern einer geänderten Rolle sieht die Person beim nächsten Seitenaufruf das angepasste Menü und die freigegebenen Funktionen.
Renaming statt Code-Änderung: Wenn Ihre Einrichtung andere Rollen-Bezeichnungen wünscht (z. B. „Tutor:in“, „Ausbildungsleiter:in“), ändern Sie nur die Renaming-Schlüssel — die Permissions bleiben identisch.
Default-Account dokumentieren: Notieren Sie extern, welche E-Mail / welcher Identifier den Default-Account darstellt. Da er in der UI versteckt ist, wäre er sonst leicht zu vergessen.
Permission-Set überprüfen: Wer Sonderfälle implementiert (z. B. Lehrkraft soll auch Stack-Vorlagen anlegen können), kann Permissions in der Datenbank über Spatie-Permissions Funktionen direkt der Rolle hinzufügen — die UI bietet aktuell keine Permission-Verwaltung.