ServiceUser

ServiceUser ist ein über ServiceLogin registrierter Endnutzer des Produkts, also ein Mitgliedskonto. Es handelt sich um eine eigenständige Identität, getrennt vom Weegloo-Plattformkonto (dem Weegloo User, der sich am Content-Studio anmeldet); das Token eines ServiceUser authentifiziert sich gegenüber ACMA/ACDA.

Ein ServiceUser entsteht, wenn sich ein Mitglied direkt über ServiceLogin registriert. Daher gibt es in dieser API keinen Endpunkt zum Erstellen, sondern nur das Abrufen und einige durch einen Administrator (Weegloo User) vorgenommene Änderungen.

Ressourcenstruktur

Im Folgenden steht die Antwort einer Einzelabfrage für einen ServiceUser. Neben sys (Systemeigenschaften) besitzt er die Hauptkörper-Eigenschaften nickname, avatarUrl, roleOverride und enableLogin, die Anzeigeinformationen des Mitglieds und Berechtigungseinstellungen enthalten.

{
  "sys": {
    "id": "3trmXRM3RqbgSnifyg7PSusr01Ex",
    "type": "ServiceUser",
    "space": { "sys": { "id": "HnQ32YiH", "type": "Refer", "targetType": "Space" } },
    "provider": "google",
    "email": "buyer@example.com",
    "createdAt": "2026-06-18T12:50:00.000Z",
    "updatedAt": "2026-06-18T12:50:00.000Z"
  },
  "nickname": "Stammkunde",
  "avatarUrl": "https://lh3.example.com/a/buyer-avatar",
  "roleOverride": null,
  "enableLogin": true
}

Wichtigste Schlüssel:

• sys.email: Die E-Mail-Adresse, mit der sich das Mitglied registriert hat. Zusammen mit sys.provider zeigt sie an, mit welchem Konto die Registrierung erfolgte.
• sys.provider: Der bei der Registrierung verwendete OAuth-Anbieter (z. B. google).
• roleOverride: Ein Refer, das eingetragen wird, um nur diesem Mitglied eine andere ServiceUserRole zuzuweisen. Ist es leer (null), gilt die Standardrolle aus ServiceLogin.

Systemeigenschaften (sys)

Jeder ServiceUser enthält gemeinsame Systemeigenschaften im sys-Objekt. space wird in der Refer-Form ({ "sys": { "id", "type": "Refer", "targetType" } }) eingetragen.

Da ein ServiceUser eine Ressource ist, die ein Mitglied durch seine eigene Registrierung erzeugt, hat sys anders als bei anderen CMA-Ressourcen kein createdBy, updatedBy oder version. Da version fehlt, wird auch bei Änderungen (PUT, PATCH) kein X-Weegloo-Version-Header gesendet. Es gibt auch kein Publish-Konzept, daher fehlen publish, archive und status.

Hauptkörper-Eigenschaften

Mitgliederverwaltung

Ein ServiceUser entsteht durch Registrierung. Über eine Änderung (PUT, PATCH) kann ein Administrator (Weegloo User) die folgenden zwei Dinge anpassen.

• roleOverride setzen/aufheben: Weist nur einem bestimmten Mitglied eine andere ServiceUserRole zu. Wird verwendet, um ein einzelnes Mitglied anders zu behandeln, etwa für eine kostenpflichtige Stufe, Moderatoren oder eine Beta-Gruppe. Das gesetzte roleOverride hat Vorrang vor dem defaultRole aus ServiceLogin.
• enableLogin umschalten: Deaktiviert blockiert es die Anmeldung dieses Mitglieds.

Ein Mitglied aus der Liste zu entfernen, erledigen Sie im Content-Studio. Die Schritte und das, was dabei mit verschwindet, behandelt Servicemitglieder verwalten.

Damit ein Mitglied auch die von anderen Mitgliedern erstellten Ressourcen bearbeiten kann, erstellen Sie eine eigene ServiceUserRole mit diesen Berechtigungen und weisen sie dem roleOverride dieses Mitglieds zu. Worauf ein Mitglied zugreift, legt die für dieses Mitglied geltende ServiceUserRole fest. Setzen Sie den createdBy-Filter einer Regel auf :self, erfasst die Aktion nur die selbst erstellten Ressourcen; ohne diesen Filter erfasst sie auch die von anderen Mitgliedern erstellten. Wie Sie die beiden Rollen getrennt anlegen, behandelt ServiceUserRole.

API

Die Basis-URL aller folgenden Endpunkte ist https://cma.weegloo.com/v1, und im Authorization-Header wird ein Bearer-Token benötigt, das sich gegenüber CMA authentifiziert. Da ein ServiceUser eine Ressource ohne version ist, wird auch bei Änderungen (PUT, PATCH) kein X-Weegloo-Version-Header gesendet. Es gibt keinen Endpunkt zum Erstellen (Erstellung erfolgt durch Registrierung).

Wenn Sie die Listenabfrage nach sys.email filtern, verwenden Sie nur Operatoren der exakten Übereinstimmung (eq, ne, in, nin). Die Adresse eines Mitglieds wird verschlüsselt gespeichert, daher lässt sich über dieser Darstellung nur entscheiden, ob sie gleich oder ungleich ist; prefix oder ein Vergleich der Reihenfolge geben ohne Fehler 0 Treffer zurück. Wenn Sie ein Mitglied über die Adresse gesucht haben und das Ergebnis leer ist, prüfen Sie zuerst den Operator. Eine Suche über einen Teil der Adresse lässt sich mit diesem Filter nicht ersetzen.

Verwandte Dokumente

• ServiceUserRole: Berechtigungsbündel, das roleOverride zugewiesen wird.
• ServiceLogin: Registrierung von Mitgliedern und Einstellung der Standardrolle (defaultRole).
• ACMA/ACDA-Überblick: Die API, die ServiceUser aufrufen.
• Mitgliederverzeichnis in einem Script lesen: Wie Sie ein Mitglied innerhalb eines Script per id oder E-Mail finden, und die dabei geltenden Einschränkungen.