Users & Roles
Das User-Management von aYOUne kombiniert klassische Rollen mit individuellen User-Rights und einer Paket-Schicht. Wer das Modell versteht, kann jeden noch so feinen Berechtigungsfall abbilden.
Das Rechte-Modell in einem Bild
Customer.packages[] ← was ist gebucht (additiv)
∪ Customer.customRights[]
│
↓ Schnittmenge
Role.rights ∪ User.customRights.rights
│
↓
Effektive Rechte
Wichtig: Pakete sind additiv, nicht restriktiv. Wenn dein Reseller ein Premium-Paket bucht, kannst du nur mehr Rechte vergeben, nicht weniger als die Role hergibt. Ein Tenant, der "nur CRM" verkaufen soll, braucht entweder ein getrimmtes Paket oder eine zugeschnittene Role.
User anlegen
In der UI: admin-v2 → Users → "+ Neuer User". Per CLI:
ay create users "max@firma.tld" \
--set first_name=Max \
--set last_name=Hanrieder \
--set role=<roleId>
Pflichtfelder:
| Feld | Beschreibung |
|---|---|
email |
Login-Identität |
first_name / last_name |
Anzeige-Name |
role |
ObjectId aus aYOUneRoles |
language |
de, en, ... |
Nach dem Anlegen erhält der User eine Begrüßungsmail mit Passwort-Reset-Link (sofern in Notifications konfiguriert).
Role-Editor
Roles bündeln Rechte zu wiederverwendbaren Sets. Der Modern Role Editor (admin-v2 v2026.x) bietet:
- Tabs pro Modul (CRM, Marketing, CMS, …)
- Live-Suche über alle Rechte
- Default-Templates (Sales-Team, Support, Read-Only) als Startpunkt
- Diff-View beim Speichern: was ändert sich für betroffene User?
Ein Right hat das Format <modul>.<entity>.<verb> — z.B. crm.consumers.view, marketing.coupons.create. Drei-Teil-Rechte werden in ayounestates als stateType:"right" gespiegelt.
Custom-Rights pro User
Manche User brauchen eine Sonderlocke ohne eigene Rolle. Dafür gibt es User.customRights.rights[]:
ay update users <id> \
--set customRights.rights='["marketing.coupons.export"]'
Diese werden zur Role addiert (nicht ersetzt). Sichtbar im User-Profil unter "Zusätzliche Rechte".
Best Practices
- Wenig Rollen, viele User: 5-10 wohldurchdachte Rollen schlagen 100 individuelle Rechte-Sets.
- Templates nutzen: Statt jede Rolle from scratch zu bauen, dupliziere ein globales Default und passe an.
- Audit aktivieren: Jede Rechteänderung landet im Audit-Trail — nutze das.
- Service-Tokens für Integrationen: Niemals einen normalen User für Webhook-Auth missbrauchen. Siehe CORS & Auth.
Deaktivieren statt löschen
Inaktive Mitarbeiter setzt du auf _status: "inactive" — die Login-Versuche werden geblockt, Audit-Spuren bleiben aber lesbar. Hartes Löschen sollte nur für Test-Accounts genutzt werden.
ay update users <id> --set _status=inactive