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), 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. Welche Aktionen verwendbar sind, unterscheidet sich von Map zu Map (siehe die Tabelle unter Berechtigungsmaps weiter unten). 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). Ein ServiceUser liest die Vorlage nur, daher legen Sie ausschließlich Read fest.
• 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).

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, media und script sind jeweils Maps mit Aktionen als Schlüsseln. Der Wert jeder Aktion ist ein Objekt mit den Regelarrays Allow (erlauben) und Deny (verweigern). Die Struktur der Maps ist dieselbe wie bei SpaceRole, die verwendbaren Aktionen unterscheiden sich jedoch von Map zu Map und sind enger gefasst als bei SpaceRole.

All bezeichnet auf einmal alle Aktionen, die in dieser Map verwendbar sind. Tragen Sie eine Aktion als Schlüssel ein, die nicht in der Tabelle steht, wird das Speichern der Rolle abgelehnt. Dass die Veröffentlichungsaktionen (Publish, Unpublish, Archive, Unarchive) in keiner Map vorkommen, liegt daran, dass von Mitgliedern erstellte Content und Media bereits beim Erstellen veröffentlicht werden (siehe ACMA).

Eine Aktion namens Save gibt es nicht. Die Berechtigung zum Ändern heißt Edit, und Save ist der Name eines Ereignisses, das ein Webhook abonniert.

"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 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. Beachten Sie jedoch: Die verwendbaren Aktionen sind die der obigen Tabelle und weichen von SpaceRole ab. Ein Beispiel, das mit :self darauf einschränkt, nur den selbst erstellten Content zu bearbeiten, zeigt direkt unten Rolle für normale Mitglieder und Administratorrolle.

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. Die Aktionsliste folgt nicht SpaceRole, sondern der Tabelle oben.

Rolle für normale Mitglieder und Administratorrolle

Ob ein Mitglied auch die Ressourcen anderer Mitglieder bearbeiten darf, entscheidet der createdBy-Filter der Regel. Setzen Sie bei derselben Aktion :self in createdBy, erfasst diese Aktion nur die vom aufrufenden Mitglied erstellten Ressourcen; lassen Sie createdBy weg, erfasst sie auch die von anderen Mitgliedern erstellten.

Die Rolle, die Sie normalen Mitgliedern geben, beschränkt Edit und Delete mit :self.

"content": {
  "Edit": {
    "Allow": [
      {
        "contentType": { "sys": { "id": "3trmXRLdJF4GBlAjtcuoZ7Pnxj8dlA", "type": "Refer", "targetType": "ContentType" } },
        "createdBy": { "sys": { "id": ":self", "type": "Refer", "targetType": "User" } }
      }
    ]
  },
  "Delete": {
    "Allow": [
      {
        "contentType": { "sys": { "id": "3trmXRLdJF4GBlAjtcuoZ7Pnxj8dlA", "type": "Refer", "targetType": "ContentType" } },
        "createdBy": { "sys": { "id": ":self", "type": "Refer", "targetType": "User" } }
      }
    ]
  }
}

Für ein Mitglied, das die Rolle eines Administrators übernehmen soll, legen Sie eine eigene Rolle an, in der bei denselben Aktionen createdBy fehlt. Die folgende Rolle öffnet nur das Löschen für die Ressourcen anderer Mitglieder und belässt das Bearbeiten bei den eigenen.

"content": {
  "Edit": {
    "Allow": [
      {
        "contentType": { "sys": { "id": "3trmXRLdJF4GBlAjtcuoZ7Pnxj8dlA", "type": "Refer", "targetType": "ContentType" } },
        "createdBy": { "sys": { "id": ":self", "type": "Refer", "targetType": "User" } }
      }
    ]
  },
  "Delete": {
    "Allow": [
      { "contentType": { "sys": { "id": "3trmXRLdJF4GBlAjtcuoZ7Pnxj8dlA", "type": "Refer", "targetType": "ContentType" } } }
    ]
  }
}

Die so erstellte Rolle weisen Sie dem roleOverride von ServiceUser zu und wenden sie damit nur auf dieses eine Mitglied an. Wenn Sie als defaultRole von ServiceLogin die Rolle für normale Mitglieder eintragen, erhalten neu registrierte Mitglieder nicht die Administratorrolle.

Bei Media funktioniert es genauso. Lassen Sie bei einer Aktion der media-Map createdBy weg, erfasst sie auch die von anderen Mitgliedern hochgeladenen Dateien. Der contentType-Filter wird allerdings nur in der content-Map verwendet und gehört daher nicht in die media-Map.

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 sind in script einer ServiceUserRole nur die beiden Aktionen All und Execute verwendbar.

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