Grundfunktion

Benutzerverwaltung

Die Benutzerverwaltung legt fest, wer sich am eigenen Mandanten anmelden kann und welche Fachmodule und Berechtigungsstufen jedem Benutzer zur Verfügung stehen. Sie ist mandantenweit — ein Mandant sieht nur seine eigenen Benutzer.

Rollenbasierte Rechte Modulspezifische Rollen Zufallspasswort-Generator

Berechtigung: Die Benutzerverwaltung ist nur für Benutzer mit der Rolle admin (oder global_admin) erreichbar — Menüpunkt Einstellungen → Benutzer in der Top-Navigation.

📋

Benutzerliste

Route: GET /user/list · Menüpfad: Einstellungen → Benutzer

Die Tabelle zeigt alle Benutzer des aktuellen Mandanten mit Benutzername, Vor-/Nachname, allen zugewiesenen Rollen-Badges und den Aktionsschaltflächen je Zeile.

Spalten & Optionen

Element	Bedeutung
Berechtigungen	Alle Rollen-Badges des Benutzers (siehe vollständige Rollenliste).
Graue Zeile	Benutzer ist deaktiviert (`disabled`) — kann sich nicht mehr anmelden.
✏️ Bearbeiten	Öffnet das Formular vorbefüllt mit den aktuellen Daten und Rollen.
🗑️ Löschen	Soft-Delete nach Bestätigungsdialog (siehe Deaktivieren & Löschen).
⏯ Aktivieren/Deaktivieren	Schaltet den Benutzer ohne Bestätigungsdialog sofort um.
✉️ Reset-E-Mail	Nur sichtbar, wenn E-Mail-Versand konfiguriert und der Benutzer eine E-Mail-Adresse hinterlegt hat.

Mandantentrennung: Jeder Zugriff auf einen einzelnen Benutzer (Bearbeiten, Löschen, Aktivieren/Deaktivieren) prüft serverseitig, dass der Zielbenutzer zum eigenen Mandanten gehört — ein Versuch über einen fremden Mandanten liefert einen Nicht-gefunden-Fehler.

➕

Benutzer anlegen

Menüpfad: Benutzer → Hinzufügen

Formular Benutzer hinzufügen mit Rollen-Checkboxen

Das Formular erscheint als Dialog. Benutzername, Vorname, Nachname und mindestens eine Rolle sind Pflichtfelder; ein Passwort ist erforderlich, sofern es nicht automatisch generiert wird.

Formularfelder

Benutzername Pflichtfeld — eindeutig je Mandant.
Vorname / Nachname Pflichtfeld
E-Mail-Adresse (optional) — Voraussetzung für Zugangsdaten-/Reset-E-Mails.
Passwort Pflichtfeld, sofern kein Zufallspasswort generiert wird.
Passwortänderung erzwingen — siehe Passwort ändern.
Berechtigungen Pflichtfeld — mindestens eine Rolle muss ausgewählt werden.

Zugangsdaten per E-Mail senden

Ist E-Mail-Versand konfiguriert, erscheint ein zusätzlicher Bereich, der nur beim Anlegen (nicht beim Bearbeiten) sichtbar ist:

→ Zugangsdaten per E-Mail senden: Verschickt nach dem Anlegen automatisch eine E-Mail mit Benutzername und Passwort an die hinterlegte Adresse.
→ Zufälliges 10-stelliges Passwort generieren: Nur sichtbar, wenn „Zugangsdaten senden" aktiviert ist. Blendet das Passwortfeld aus und lässt den Server ein zufälliges Passwort erzeugen (uid.GenerateRandomPassword()), das ausschließlich per E-Mail mitgeteilt wird.

Schritt für Schritt

Schaltfläche Hinzufügen anklicken.
Benutzername, Vor- und Nachname eingeben, optional E-Mail-Adresse.
Passwort vergeben oder ein Zufallspasswort generieren lassen.
Mindestens eine Rolle aus der Liste ankreuzen (siehe Rollenübersicht).
Speichern — der Benutzer erscheint sofort in der Liste.

✏️

Benutzer bearbeiten & Rollen zuweisen

✏️-Schaltfläche in der Benutzerliste

Formular Benutzer bearbeiten mit vorausgewählten Rollen

Das Bearbeitungsformular ist identisch mit dem Anlege-Formular und vorbefüllt mit den aktuellen Daten. Das Passwortfeld bleibt leer — es wird nur überschrieben, wenn ein neuer Wert eingegeben wird. Der Bereich „Zugangsdaten senden" entfällt beim Bearbeiten.

Rollenhierarchie

rk kennt vier globale Rollen mit aufsteigenden Rechten sowie modulspezifische Rollen der Form <modul>:<stufe>. Eine höhere globale Rolle schließt automatisch die darunterliegenden mit ein (User.HasRole()):

Rolle	Geltungsbereich	Bedeutung
global_admin	Systemweit	Höchste Berechtigung. Sieht/verwaltet alle Mandanten und den Systemstatus. Erfüllt automatisch jede andere Rollenprüfung.
admin	Mandantenweit	Verwaltet Benutzer und Einsätze des eigenen Mandanten. Erfüllt automatisch `user` und alle `<modul>:user`/`:guest`-Prüfungen.
user	Mandantenweit	Normale Mitarbeit in Einsätzen. Erfüllt automatisch jede `<modul>:user`/`:guest`-Prüfung — modulspezifische Rollen sind für Vollzugriff also meist gar nicht nötig.
guest	Mandantenweit	Nur-Lese-Zugriff. Erfüllt automatisch jede `<modul>:guest`-Prüfung.

Modulspezifische Rollen

Modulspezifische Rollen erlauben eine feinere Abstufung, ohne einem Benutzer gleich die globale user- oder admin-Rolle (und damit Zugriff auf alle Module) zu geben — z. B. ein externer Helfer, der ausschließlich im Patientenmodul mitarbeiten soll:

Modul	admin	user	guest
Einsatztagebuch (ETB)	—	`missionDiary:user`	`missionDiary:guest`
Stab (MissionControl)	`missionControl:admin`	`missionControl:user`	`missionControl:guest`
Patienten / UHS	`patient:admin`	`patient:user`	`patient:guest`
Bereitstellungsraum	`stagingRoom:admin`	`stagingRoom:user`	`stagingRoom:guest`
Lagekarte	—	`map:user`	`map:guest`
Evakuierung (Shelter)	`shelter:admin`	`shelter:user`	`shelter:guest`

Innerhalb eines Moduls gilt dieselbe Hierarchie wie global: <modul>:admin erfüllt automatisch <modul>:user und <modul>:guest, <modul>:user erfüllt automatisch <modul>:guest.

Praxistipp: Für reguläre Einsatzkräfte reicht in den meisten Fällen die globale Rolle user aus — sie schließt automatisch Lese- und Schreibzugriff auf alle lizenzierten Module mit ein. Modulspezifische Rollen lohnen sich vor allem für Benutzer, die nicht auf alle Module zugreifen sollen (z. B. nur Lagekarte und Patienten, aber kein Stab).

🚫

Deaktivieren & Löschen

Schaltflächen in der Benutzerliste

Benutzerliste mit Aktionsschaltflächen Bearbeiten, Löschen und Aktivieren/Deaktivieren

rk unterscheidet bewusst zwischen zwei Aktionen mit unterschiedlicher Tragweite:

⏯ Aktivieren / Deaktivieren — reversibel, ohne Bestätigung

Schaltet sofort den Zustand disabled um. Ein deaktivierter Benutzer kann sich nicht mehr anmelden (Login prüft u.Disabled), bleibt aber inklusive aller Daten erhalten und erscheint grau hinterlegt in der Liste. Bereits offene Sitzungen des Benutzers werden über WebSocket sofort zu einem Reload aufgefordert.

🗑️ Löschen — Soft-Delete, mit Bestätigungsdialog

Fragt zunächst „Benutzer wirklich löschen?" über einen Bestätigungsdialog des Browsers ab. Erst nach Bestätigung wird der Benutzer per Soft-Delete markiert (deleted_at gesetzt) — er verschwindet aus der Liste, sein Benutzername bleibt aber für eine künftige Neuanlage gesperrt (eindeutiger Index auf Benutzername + Mandant + deleted_at). Auch hier werden offene Sitzungen sofort beendet.

Eigener Account: Es gibt serverseitig keine besondere Sperre gegen das Deaktivieren oder Löschen des eigenen Kontos — gehen Sie hier insbesondere als letzter verbleibender Administrator eines Mandanten mit Vorsicht vor.

📧

Passwort-Reset-E-Mail erneut senden

Route: GET /user/{id}/sendResetEmail · ✉️-Schaltfläche in der Benutzerliste

Statt selbst ein neues Passwort zu vergeben, kann ein Administrator dem Benutzer stattdessen einen frischen Passwort-Reset-Link zusenden — der Benutzer wählt sein Passwort dann selbst, ohne dass der Administrator es kennt.

Voraussetzungen

→E-Mail-Versand muss serverseitig konfiguriert sein — sonst ist die Schaltfläche gar nicht erst sichtbar.
→Der Zielbenutzer muss eine E-Mail-Adresse hinterlegt haben.

Ablauf

In der Benutzerliste auf das ✉️-Symbol der gewünschten Zeile klicken.
rk erzeugt einen neuen Reset-Token und versendet den Link sofort.
Ein zuvor bereits ausgestellter, noch nicht eingelöster Reset-Link bleibt unabhängig davon weiter gültig, bis er verwendet oder durch einen neuen ersetzt wird.

Typischer Einsatzzweck: Ein neu angelegter Benutzer hat seine Zugangsdaten-E-Mail nicht erhalten oder verloren — statt das Konto erneut anzulegen, reicht ein Klick auf „Reset-E-Mail senden".