Zum Inhalt

Users & Tenants

Tenants

Ein Tenant ist die Mandanten-Trennlinie — typisch ein Kunde oder eine Abteilung.

Anlegen

/admin/tenants → Neu:

Feld Bedeutung
Name Anzeigename
Slug URL-Slug, eindeutig
Branding Logo, Farbe (für Status-Pages und PDFs)
Notes optional

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. deletion_batch_id verbindet sie — Restore in der Papierkorb-UI restauriert die ganze Familie.

Endgültiges Löschen nach 30 Tagen oder via Admin-Purge.

Cross-Tenant-Sichtbarkeit

Default: Nutzer sieht nur seinen eigenen Tenant.

Super-Admin: alle Tenants. Sichtbar in der Tenant-Drop-Down oben links.

Custom-Rollen können tenant.cross_view haben — dann sieht der User mehrere Tenants ohne Super-Admin-Status.

Users

Anlegen

/admin/users → Neu:

Feld Bedeutung
E-Mail Login
Vorname / Nachname Anzeigename
Tenant bei Super-Admin: optional, sonst feste Bindung
Rolle Default oder Custom
Aktiv Toggle
Passwort optional setzen oder Einladungs-Mail

Einladungs-Mail

Wenn du beim Anlegen kein Passwort setzt, schickt Vesana eine Einladungs-Mail mit Setup-Link. Der User klickt, setzt Passwort + 2FA, ist aktiv.

Voraussetzung: SMTP konfiguriert (siehe Setup-Wizard).

Passwort vergessen

Login-Seite → Passwort vergessen → E-Mail mit Reset-Link.

Reset-Token sind 1 h gültig, Single-Use.

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_id — dass dieser User existiert hat.

JWT vs. DB-User

Aktive JWT-Tokens enthalten User-IDs (sub). Bei Soft-Delete bleibt der User in der DB — JWT bleibt gültig bis Ablauf. Bei Hard-Delete-Cascade nach 30 Tagen verschwindet der User aus der DB, aber FK-Constraints auf users(id) wurden bewusst entfernt (siehe Architektur-Hinweis in CLAUDE.md), damit alte JWTs nicht zu DB-Fehlern führen.

User wechseln Tenants?

Nicht direkt. Workflow:

  1. User im alten Tenant deaktivieren
  2. Neuen User-Eintrag im neuen Tenant anlegen mit gleicher E-Mail
  3. Überlappung der Logins kurzzeitig manuell auflösen

Mein-Konto-Sicht

Jeder User unter /profile:

  • E-Mail (read-only nach Anlage)
  • Anzeigename ändern
  • Passwort ändern
  • 2FA aktivieren / Recovery-Codes
  • Sprache (DE/EN)
  • Theme
  • AI-Sichtbarkeit (hide_ai)
  • API-Keys verwalten (Pro+)

API-Keys (Personal-Access-Tokens)

Alternative zu Browser-Login für CLI/Scripts:

/profile → 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 host.create kann nur in seinem Tenant Hosts anlegen. Cross-Tenant-Operationen brauchen Super-Admin oder spezielle Custom-Roles.

Details: Rollen & Permissions.

Anschluss