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.

EigenschaftTypBeschreibung
idstringEindeutiger Bezeichner der Ressource.
typestringArt der Ressource. Bei ServiceUserRole immer "ServiceUserRole".
spaceRefer<Space>Der Space, zu dem diese ServiceUserRole gehört.
createdByRefer<User>Der Benutzer, der sie erstellt hat.
createdAtstring (date-time)Zeitpunkt der Erstellung.
updatedByRefer<User>Der Benutzer, der sie zuletzt geändert hat.
updatedAtstring (date-time)Zeitpunkt der letzten Änderung.
versioninteger (≥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 ein Refer eingesetzt, der auf einen Content Type verweist.
  • createdBy: Beschränkt auf Ressourcen, die ein bestimmter Benutzer erstellt hat. Mit einer bestimmten id in sys.id werden nur die von dieser Person erstellten Ressourcen erfasst; mit dem reservierten Wert :self wird 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 :self richten sich nach der Berechtigungsregeldefinition weegloo-space-role. Bei ServiceUserRole wird :self auf 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.

  • 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).