ServiceUserRole

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), ob sie ein Script ausführen können, 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.

ServiceUserRole 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, media und script, 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": [] } },
  "script": {}
}

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).
• script: Berechtigungsmap für Script (deklarative Backend-Endpunkte). Ein ServiceUser führt ein Script nur aus (Execute), daher setzen Sie üblicherweise nur Execute.

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.

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 verwendbaren Aktionen sind Create (Erstellen), Read (Lesen), Edit (Bearbeiten), Delete (Löschen), Publish (Veröffentlichen), Unpublish (Veröffentlichung zurücknehmen), Archive (Archivieren) und Unarchive (Archivierung aufheben); zusätzlich gibt es All, das alle Aktionen auf einmal abdeckt. Save bedeutet dasselbe wie Edit. 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.

• self: Beschränkt das Ziel, auf das die Regel angewendet wird, auf die Ressource selbst. In der contentType-Map bedeutet es genau einen bestimmten Content Type, in der script-Map genau ein bestimmtes Script.
• contentType: Beschränkt auf den Content Type, zu dem dieser Content gehört. 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.

Welcher Filter in welcher Berechtigungsmap gültig ist, ist dasselbe wie bei SpaceRole (in der contentType-Map geben Sie das Ziel mit self an, in der content-Map mit contentType), und bei einem unpassenden Filter wird das Speichern der Rolle abgelehnt. Die Tabelle je Map finden Sie unter Berechtigungs-Maps bei SpaceRole.

Wenn Sie den createdBy-Filter (einschließlich :self) über ACDA anwenden, muss publishWithAuthor des betreffenden Content Type true sein. ACDA wertet diesen Filter anhand von sys.createdBy im Veröffentlichungs-Snapshot aus; ist publishWithAuthor der Standardwert false, enthält der Snapshot keine Autoreninformationen, sodass die Allow-Regel nichts trifft (das Mitglied erhält seine eigenen Ressourcen als leeres Ergebnis) und die Deny-Regel niemanden herausfiltert. ACMA (Verwaltung) wertet dagegen anhand von sys.createdBy des Entwurfs aus und ist daher von dieser Einstellung unabhängig, sodass dieselbe Regel unter ACMA funktionieren, unter ACDA jedoch fehlschlagen kann. publishWithAuthor muss eingeschaltet werden, bevor ein Mitglied einen Beitrag einstellt, und wirkt nicht rückwirkend. Siehe die Beschreibung von publishWithAuthor bei Content Type.

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 die vier Berechtigungsmaps contentType, content, media und script. 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 (Create, Read, Edit, Save, Delete, Publish, Unpublish, Archive, Unarchive, All), die Filterschlüssel (self, contentType, createdBy, tag) und die Bedeutung von :self richten sich nach der Definition der Berechtigungsregeln bei SpaceRole. Bei ServiceUserRole wird :self auf die vom aktuellen ServiceUser erstellten Ressourcen aufgelöst.

script (Script-Berechtigungen)

script ist die Berechtigungsmap für Script; ihre Struktur ist dieselbe wie bei content und media. Allerdings kann ein ServiceUser ein Script nur ausführen (das Verfassen, also Erstellen, Bearbeiten und Löschen, ist CMA / Weegloo User vorbehalten). Daher ist in einer ServiceUserRole die einzige Aktion, die Sie in script sinnvoll verwenden, Execute.

Damit ein registriertes Mitglied ein Script ausführen kann, schreiben Sie dies:

"script": {
  "Execute": { "Allow": [] }
}

Als Regelfilter lassen sich die beiden self (genau ein bestimmtes Script) und createdBy verwenden. contentType und tag sind keine Achsen, die an einem Script hängen, daher wird das Speichern der Rolle bei ihrem Eintrag abgelehnt. Wenn Sie einem Mitglied erlauben möchten, nur ein einziges bestimmtes Script auszuführen, setzen Sie in das Allow von Execute eine self-Regel, die auf dieses Script verweist.

"script": {
  "Execute": {
    "Allow": [
      { "self": { "sys": { "id": "3trmXRMZcTAjDnphewjj1AaxYcaxlK", "type": "Refer", "targetType": "Script" } } }
    ]
  }
}

Die Struktur von Script selbst sowie dessen Endpunkt zum Ausführen werden unter Script-Ressource und Endpunkte behandelt, die vollständige Aktionsliste unter der script-Berechtigung bei SpaceRole.

Fehler

Dies sind die Codes, die beim Umgang mit einer ServiceUserRole auftreten. Codes, die allen Ressourcen gemeinsam sind, finden Sie unter Gemeinsame Fehler.

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