ServiceUserRole
Zuletzt aktualisiert: 3. Juli 2026
ServiceUserRole ist ein Berechtigungsbündel, das den im Produkt registrierten Endnutzern, also den ServiceUser, zugewiesen wird. Es legt in einer einzigen Ressource fest, was diese mit Content Type, Content und Media tun dürfen (Lesen, Erstellen, Bearbeiten, Löschen, Veröffentlichen), sowie Filter, die den Umfang einschränken, etwa nur auf bestimmte Content Type oder nur auf selbst erstellte Ressourcen. Diese Berechtigungen gelten für ACMA/ACDA, die der ServiceUser aufruft.
Es steht an einer anderen Stelle als SpaceRole. SpaceRole ist das Berechtigungsbündel eines Weegloo User (Content-Studio-Benutzers) und gilt für CMA/CDA, während ServiceUserRole das Berechtigungsbündel eines im Produkt registrierten ServiceUser ist und für ACMA/ACDA gilt. Eine erstellte ServiceUserRole gilt für sich allein für niemanden. Sie wird wirksam, indem Sie sie der Standardrolle (defaultRole) von ServiceLogin zuweisen oder an roleOverride von ServiceUser binden.
Ressourcenstruktur
Im Folgenden sehen Sie die Antwort einer Einzelabfrage der ServiceUserRole "Käufer". Neben sys (Systemeigenschaften) besitzt sie die inhaltlichen Eigenschaften contentType, content und media, die die Berechtigungen festlegen.
{
"sys": {
"id": "3trmXRLXeZN2RTHvVj3hFDN5546vbp",
"type": "ServiceUserRole",
"space": { "sys": { "id": "HnQ32YiH", "type": "Refer", "targetType": "Space" } },
"createdBy": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } },
"createdAt": "2026-06-18T12:40:36.944Z",
"updatedBy": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } },
"updatedAt": "2026-06-18T12:40:36.944Z",
"version": 1
},
"name": "Käufer",
"description": "Mitglied, das veröffentlichte Produkte lesen kann",
"contentType": { "All": { "Allow": [] } },
"content": {
"Read": {
"Allow": [
{ "contentType": { "sys": { "id": "3trmXRLdJF4GBlAjtcuoZ7Pnxj8dlA", "type": "Refer", "targetType": "ContentType" } } }
]
}
},
"media": { "All": { "Allow": [] } }
}Wichtigste Schlüssel:
contentType: Berechtigungsmap für den Content Type selbst (das Schema). Legt pro Aktion fest, ob ein Content Type gelesen, erstellt, bearbeitet, gelöscht und veröffentlicht werden darf.content: Berechtigungsmap für Content (die Inhaltsdaten). Das obige Beispiel zeigt eine Beschränkung darauf, nur den Content eines bestimmten Content Type zu lesen.media: Berechtigungsmap für Media (Dateien und Bilder).
Anders als SpaceRole hat ServiceUserRole kein settings, das den Zugriff auf die Space-Einstellungen abbildet. Der Grund ist, dass ein ServiceUser die Space-Einstellungen nicht verwaltet. Außerdem gibt es kein sys.isLocked, das anzeigt, ob die Rolle vorgegeben ist.
Systemeigenschaften (sys)
Jede ServiceUserRole enthält die gemeinsamen Systemeigenschaften im sys-Objekt. space, createdBy und updatedBy liegen in der Refer-Form ({ "sys": { "id", "type": "Refer", "targetType" } }) vor.
| Eigenschaft | Typ | Beschreibung |
|---|---|---|
id | string | Eindeutiger Bezeichner der Ressource. |
type | string | Art der Ressource. Bei ServiceUserRole immer "ServiceUserRole". |
space | Refer<Space> | Der Space, zu dem diese ServiceUserRole gehört. |
createdBy | Refer<User> | Der Benutzer, der sie erstellt hat. |
createdAt | string (date-time) | Zeitpunkt der Erstellung. |
updatedBy | Refer<User> | Der Benutzer, der sie zuletzt geändert hat. |
updatedAt | string (date-time) | Zeitpunkt der letzten Änderung. |
version | integer (≥1) | Version der Ressource. Wird bei jeder Änderung um 1 erhöht. |
ServiceUserRole ist eine Konfigurationsressource ohne Veröffentlichungskonzept. Anders als Content und Media enthält sys daher kein publish, archive oder status, sondern nur version. version wird bei jeder Änderung der ServiceUserRole erhöht. Anders als SpaceRole gibt es auch kein sys.isLocked.
Berechtigungsmaps: contentType, content, media
contentType, content und media sind jeweils Maps mit Aktionen als Schlüsseln. Die Aktionen sind Read (Lesen), Create (Erstellen), Edit (Bearbeiten), Delete (Löschen) und Publish (Veröffentlichen); zusätzlich gibt es All, das alle Aktionen auf einmal abdeckt. Der Wert jeder Aktion ist ein Objekt mit den Regelarrays Allow (erlauben) und Deny (verweigern). Diese Struktur der Berechtigungsmap ist dieselbe wie bei SpaceRole.
"content": {
"Read": { "Allow": [ /* Regel */ ], "Deny": [ /* Regel */ ] },
"Edit": { "Allow": [ /* Regel */ ] }
}Jedes Regelobjekt (rule) besitzt optionale Filter, die den Berechtigungsumfang einschränken.
contentType: Beschränkt das Ziel, auf das die Regel angewendet wird, auf genau einen Content Type. Hier wird einRefereingesetzt, der auf einen Content Type verweist.createdBy: Beschränkt auf Ressourcen, die ein bestimmter Benutzer erstellt hat. Mit einer bestimmten id insys.idwerden nur die von dieser Person erstellten Ressourcen erfasst; mit dem reservierten Wert:selfwird auf "nur die vom aktuell aufrufenden ServiceUser erstellten" beschränkt.tag: Beschränkt auf Ressourcen, die mit einem bestimmten Tag versehen sind.
Ein leeres Allow-Array [] bedeutet, dass die Aktion für die gesamte Ressourcenart erlaubt ist. Da der Filter leer ist, gibt es nichts auszufiltern, sodass die Aktion für alle Ressourcen geöffnet ist.
Anders als SpaceRole hat ServiceUserRole kein settings. Es gibt nur die drei Berechtigungsmaps contentType, content und media. Die Aktionsliste, die Filterschlüssel und die Bedeutung von :self sowie das Erstellen der Berechtigungsmap finden Sie ergänzend auch in der Beschreibung von SpaceRole, die dieselbe Struktur verwendet. Ein Beispiel, das mit :self darauf einschränkt, nur den selbst erstellten Content zu bearbeiten, zeigt der Block zur Änderung weiter unten.
Die Aktionsliste (
Read,Create,Edit,Delete,Publish,All), die Filterschlüssel (contentType,createdBy,tag) und die Bedeutung von:selfrichten sich nach der Berechtigungsregeldefinitionweegloo-space-role. Bei ServiceUserRole wird:selfauf die vom aktuellen ServiceUser erstellten Ressourcen aufgelöst.
API
Die Basis-URL aller folgenden Endpunkte ist https://cma.weegloo.com/v1, und im Authorization-Header wird ein Bearer-Token benötigt, der sich gegenüber CMA authentifiziert. Bei der Rollenänderung (PUT, PATCH) muss zur optimistischen Nebenläufigkeitskontrolle zusätzlich der Header X-Weegloo-Version (die sys.version der aktuellen Ressource) gesendet werden. Beim Erstellen und Löschen entfällt dieser Header.
Verwandte Dokumente
- ServiceUser: Das registrierte Mitglied, das diese Rolle erhält (
roleOverride). - ServiceLogin: Weist die ServiceUserRole als Standardrolle (
defaultRole) zu. - SpaceRole: Berechtigungsbündel für Weegloo User (gleiche Struktur der Berechtigungsmap).
