Users & Tenants¶
Admin → Zugriff — Tab „Tenants" und Tab „Users".
Tenants¶
Ein Tenant ist die Mandanten-Trennlinie — typisch ein Kunde oder eine Abteilung.
Anlegen¶
Admin → Zugriff → Tenants → Neu:
| Feld | Bedeutung |
|---|---|
| Name | Anzeigename |
| Slug | URL-Slug, eindeutig |
| Branding | Logo, Farbe (für Status-Pages und PDFs) |
| Notes | optional |
Tenant-Anlage ist eine Super-Admin-Funktion — sie ist bewusst nicht über eine eigene delegierbare Permission an andere Rollen vergebbar.
Daten pro Tenant¶
Nach Anlage hat ein Tenant:
- 0 Hosts
- 0 Custom Dashboards
- Default-Alert-Channel-Templates (leer)
- Audit-Log
Du kannst direkt Hosts anlegen, Profile sind tenant-übergreifend (Builtins) verfügbar.
Tenant löschen¶
Soft-Delete kaskadiert: alle Hosts, Services, Alerts des Tenants werden mit-soft-deleted (gemeinsame Löschgruppe) — Restore in der Papierkorb-UI restauriert die ganze Familie.
Endgültiges Löschen nach 30 Tagen oder via Admin-Purge.
Cross-Tenant-Sichtbarkeit¶
Jeder User hat ein Feld Tenant-Zugriff: entweder all (alle Tenants, unabhängig von der Rolle) oder selected (eine explizit zugewiesene Liste von Tenants). Super-Admins haben typischerweise all; ein normaler User mit selected sieht nur die ihm zugewiesenen Tenants und wechselt zwischen ihnen über die Tenant-Dropdown oben links.
Das ist unabhängig von der Rolle: ein Operator kann in mehreren Tenants gleichzeitig Zugriff haben, ohne Super-Admin zu sein — dafür einfach mehrere Tenants beim Anlegen/Bearbeiten des Users zuweisen.
Users¶
Anlegen¶
Admin → Benutzer & Tenants → Benutzer → Neu:
| Feld | Bedeutung |
|---|---|
| Benutzername | Login — ein einfacher Name wie admin reicht, eine E-Mail-Adresse ist nicht nötig (Vesana verschickt keine Mails an Benutzer) |
| Vorname / Nachname | Anzeigename |
| Tenant-Zugriff | all oder eine Auswahl konkreter Tenants |
| Rolle | Default oder Custom |
| Aktiv | Toggle |
| Passwort | wird beim Anlegen gesetzt; der Benutzer ändert es danach selbst (Einstellungen → Sicherheit) |
Passwort vergessen¶
Es gibt keinen Reset-Link per E-Mail. Ein Admin setzt das Passwort in der Benutzerzeile neu — dabei werden alle Sitzungen des Benutzers beendet, und er meldet sich mit dem neuen Passwort an.
Aktionen in der Benutzerzeile¶
Jede Aktion steht als Symbol rechts in der Zeile und im Rechtsklick-Menü (ab v1.9.437): Bearbeiten, Passwort setzen, Deaktivieren, Alle Sitzungen abmelden (fragt nach und meldet zurück, wie viele Sitzungen betroffen waren), 2FA zurücksetzen (siehe 2FA). Nicht mögliche Aktionen sind ausgegraut und nennen den Grund. Die Liste zeigt außerdem, wer TOTP oder Passkeys eingerichtet hat. Ein gelöschter Benutzer gibt seinen Namen sofort wieder frei — der Papierkorb-Eintrag trägt das Löschdatum im Namen.
Account aktiv / inaktiv¶
Statt User zu löschen, Aktiv = false setzen. Vorteile:
- Audit-Log behält den User-Verweis
- Re-Aktivierung möglich
- Dashboard-Owner-Beziehungen bleiben
Inaktiver User kann sich nicht einloggen, alle Tokens sind invalidiert.
Soft-Delete¶
Echtes Löschen ist Soft-Delete (siehe Papierkorb). Audit-Log behält weiter den User-Verweis — dass dieser User existiert hat.
JWT vs. DB-User
Aktive Login-Tokens enthalten die User-ID. Bei Soft-Delete bleibt der User in der DB — bestehende Tokens bleiben bis zu ihrem Ablauf gültig. Nach dem endgültigen Löschen verschwindet der User aus der DB, ohne dass alte Tokens zu Serverfehlern führen.
User wechseln Tenants?¶
Nicht direkt als „Umzug" — stattdessen einfach den Tenant-Zugriff des Users anpassen: neuen Tenant zur Auswahl hinzufügen, alten entfernen. Bei getrennten Logins (unterschiedliche Rollen je Tenant nötig) hilft ein zweiter User-Eintrag mit anderer E-Mail-Adresse.
Mein-Konto-Sicht¶
Jeder User unter „Mein Konto":
- Benutzername (read-only nach Anlage)
- Anzeigename ändern
- Passwort ändern
- 2FA einrichten (Authenticator-App oder Sicherheitsschlüssel) — siehe 2FA
- Sprache (DE/EN)
- Theme
- AI-Sichtbarkeit
- API-Keys verwalten
API-Keys (Personal-Access-Tokens)¶
Alternative zu Browser-Login für CLI/Scripts:
„Mein Konto" → API-Keys → Neu:
- Name + Ablauf-Datum
- Scope (read-only / read-write)
- Token wird genau einmal angezeigt
In Anfragen: Authorization: Bearer <token>.
Widerrufen jederzeit möglich; alter Token-Hash wird invalidiert.
Permissions vs. Tenant-Scope¶
Permissions sind tenant-skopiert: ein User mit hosts.create kann nur in den ihm zugänglichen Tenants Hosts anlegen. Rollen- und Tenant-Verwaltung selbst bleiben Super-Admin-Funktionen.
Details: Rollen & Permissions.