ServiceUserRole

ServiceUserRole est l'ensemble de permissions accordé à un end-user inscrit au produit, c'est-à-dire à un ServiceUser. Il regroupe dans une seule ressource ce qu'il peut faire (lire, créer, modifier, supprimer) sur les Content Type, Content et Media, s'il peut exécuter un Script, ainsi que les filtres qui restreignent la portée (par exemple seulement certains Content Type, ou seulement ce qu'il a lui-même créé). Les actions utilisables diffèrent d'une carte à l'autre (voir le tableau Cartes de permissions ci-dessous). Ces permissions s'appliquent à ACMA/ACDA, que le ServiceUser appelle.

La place de ServiceUserRole diffère de celle de SpaceRole. SpaceRole est l'ensemble de permissions d'un Weegloo User (utilisateur du studio de contenu) et s'applique à CMA/CDA, tandis que ServiceUserRole est l'ensemble de permissions d'un ServiceUser inscrit au produit et s'applique à ACMA/ACDA. Un ServiceUserRole créé ne s'applique à personne en lui-même. Vous l'attribuez en le désignant comme rôle par défaut (defaultRole) d'un ServiceLogin ou en le liant au roleOverride d'un ServiceUser.

Structure de la ressource

Voici la réponse d'une lecture unitaire du ServiceUserRole « Acheteur ». Avec sys (propriétés système), il possède les propriétés de corps contentType, content, media et script qui définissent les permissions.

{
  "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": "Acheteur",
  "description": "Membre pouvant lire les produits publiés",
  "contentType": { "All": { "Allow": [] } },
  "content": {
    "Read": {
      "Allow": [
        { "contentType": { "sys": { "id": "3trmXRLdJF4GBlAjtcuoZ7Pnxj8dlA", "type": "Refer", "targetType": "ContentType" } } }
      ]
    }
  },
  "media": { "All": { "Allow": [] } },
  "script": {}
}

Clés principales :

• contentType : carte de permissions sur le Content Type lui-même (le schéma). Un ServiceUser ne fait que lire le formulaire, vous n'y définissez donc que Read.
• content : carte de permissions sur le Content (les données de contenu). L'exemple ci-dessus restreint la lecture aux seuls Content d'un Content Type précis.
• media : carte de permissions sur le Media (fichiers et images).
• script : carte de permissions sur le Script (endpoints backend déclaratifs). Un ServiceUser ne fait qu'exécuter (Execute) un Script.

Contrairement à SpaceRole, ServiceUserRole n'a pas de settings portant l'accès aux paramètres du Space. C'est parce qu'un ServiceUser ne gère pas les paramètres du Space. Il n'a pas non plus de sys.isLocked, qui indique s'il s'agit d'un rôle fourni par défaut.

Propriétés système (sys)

Chaque ServiceUserRole porte des propriétés système communes dans l'objet sys. space, createdBy et updatedBy ont la forme Refer ({ "sys": { "id", "type": "Refer", "targetType" } }).

ServiceUserRole est une ressource de configuration sans notion de publication. C'est pourquoi, contrairement à Content et Media, son sys n'a pas de publish, archive ni status, et ne possède que version. La version augmente à chaque modification du ServiceUserRole. Contrairement à SpaceRole, il n'a pas non plus de sys.isLocked.

Cartes de permissions : contentType, content, media

contentType, content, media et script sont chacune une carte dont les clés sont des actions. La valeur de chaque action est un objet contenant les tableaux de règles Allow (autorisation) et Deny (refus). La structure des cartes est identique à celle de SpaceRole, mais les actions utilisables diffèrent d'une carte à l'autre et sont plus restreintes que celles de SpaceRole.

All désigne d'un coup toutes les actions utilisables dans cette carte. Mettre en clé une action absente du tableau fait refuser l'enregistrement du rôle. Si les actions de publication (Publish, Unpublish, Archive, Unarchive) ne figurent dans aucune carte, c'est parce que les Content et Media créés par un membre sont publiés dès leur création (voir ACMA).

Il n'existe pas d'action Save. La permission de modification est Edit, et Save est le nom d'un événement auquel s'abonne un Webhook.

"content": {
  "Read":   { "Allow": [ /* règle */ ], "Deny": [ /* règle */ ] },
  "Edit":   { "Allow": [ /* règle */ ] }
}

Chaque objet règle (rule) possède des filtres facultatifs qui restreignent la portée de la permission.

• self : limite la cible de la règle à la ressource elle-même. Dans le mappage contentType, cela désigne un seul Content Type ; dans le mappage script, un seul Script.
• contentType : limite au Content Type auquel appartient ce Content. On y place un Refer désignant un Content Type.
• createdBy : limite aux seules ressources créées par un utilisateur précis. Si vous mettez un id précis dans sys.id, seules les ressources créées par cette personne sont concernées ; si vous mettez la valeur réservée :self, la restriction devient « seulement ce qu'a créé le ServiceUser qui appelle actuellement ».
• tag : limite aux seules ressources portant un Tag précis.

Le mappage de permissions dans lequel chaque filtre est valide est le même que pour SpaceRole (le mappage contentType désigne sa cible avec self, le mappage content avec contentType) et y placer un filtre qui ne convient pas fait refuser l'enregistrement du rôle. Le tableau par mappage figure dans les cartes de permissions de SpaceRole.

Pour appliquer le filtre createdBy (y compris :self) sur ACDA, le publishWithAuthor du Content Type visé doit valoir true. ACDA évalue ce filtre à partir du sys.createdBy de l'instantané de publication ; si publishWithAuthor conserve sa valeur par défaut false, l'instantané ne contient pas d'auteur, de sorte que les règles Allow ne correspondent à rien (le membre reçoit ses propres ressources sous la forme d'un résultat vide) et que les règles Deny n'écartent personne. À l'inverse, ACMA (gestion) évalue à partir du sys.createdBy du brouillon et ne dépend donc pas de ce paramètre, si bien qu'une même règle peut fonctionner sur ACMA tout en étant faussée sur ACDA. publishWithAuthor doit être activé avant que le membre ne publie son contenu, et n'est pas rétroactif. Reportez-vous à l'explication de publishWithAuthor du Content Type.

Un tableau Allow vide [] signifie que l'action est autorisée sur l'ensemble du type concerné. Le filtre étant vide, il n'y a rien à écarter, donc l'action est ouverte sur toutes les ressources.

Contrairement à SpaceRole, ServiceUserRole n'a pas de settings. Les cartes de permissions sont les quatre suivantes : contentType, content, media et script. Pour les clés de filtre et le sens de :self, ainsi que la manière de rédiger une carte de permissions, reportez-vous aussi à l'explication de SpaceRole, qui utilise la même structure. Toutefois, les actions utilisables sont celles du tableau ci-dessus et diffèrent de celles de SpaceRole. Un exemple qui restreint la modification aux seuls Content créés par soi-même à l'aide de :self est présenté juste en dessous, dans Rôle de membre ordinaire et rôle d'administrateur.

Les clés de filtre (self, contentType, createdBy, tag) et le sens de :self suivent la définition des règles de permissions de SpaceRole. Pour ServiceUserRole, :self se résout en « seulement ce qu'a créé le ServiceUser actuel ». La liste des actions ne suit pas SpaceRole : elle suit le tableau ci-dessus.

Rôle de membre ordinaire et rôle d'administrateur

Ce qui détermine si un membre peut manipuler aussi les ressources des autres membres, c'est le filtre createdBy de la règle. Pour une même action, mettre :self dans createdBy fait que l'action ne porte que sur ce qu'a créé le membre appelant ; ne pas renseigner createdBy étend la cible à ce qu'ont créé les autres membres.

Le rôle attribué aux membres ordinaires restreint Edit et Delete à :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" } }
      }
    ]
  }
}

Pour un membre appelé à jouer le rôle d'administrateur, créez à part un rôle dont ces mêmes actions ne comportent pas createdBy. Le rôle ci-dessous n'ouvre que la suppression aux ressources des autres membres et laisse la modification limitée aux siennes.

"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" } } }
    ]
  }
}

Le rôle ainsi créé s'applique à ce seul membre en le désignant dans le roleOverride d'un ServiceUser. Si vous laissez le defaultRole de ServiceLogin sur le rôle de membre ordinaire, les membres qui s'inscrivent ne reçoivent pas le rôle d'administrateur.

Il en va de même pour Media. Retirer createdBy d'une action de la carte media étend la cible aux fichiers téléversés par les autres membres. Toutefois, le filtre contentType ne s'utilisant que dans la carte content, on ne le place pas dans la carte media.

script (permissions Script)

script est la carte de permissions sur le Script ; sa structure est identique à celle de content et media. Toutefois, la seule chose qu'un ServiceUser puisse faire à un Script est de l'exécuter (l'écriture, c'est-à-dire créer/modifier/supprimer, est réservée à CMA / Weegloo User). C'est pourquoi, dans un ServiceUserRole, les seules actions utilisables dans script sont All et Execute.

Pour permettre à un membre inscrit d'exécuter un Script :

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

Les filtres de règle utilisables sont self (un seul Script) et createdBy. contentType et tag sont des axes qui ne s'attachent pas au Script : les y placer fait refuser l'enregistrement du rôle. Pour n'autoriser un membre à exécuter qu'un seul Script, on place dans le Allow de Execute une règle self désignant ce Script.

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

La structure du Script lui-même ainsi que son endpoint d'exécution sont traités dans Ressource Script et endpoints ; la liste complète des actions est traitée dans la permission script de SpaceRole.

Erreurs

Ce sont les codes que l'on rencontre lorsque l'on manipule un ServiceUserRole. Pour les codes communs à toutes les ressources, consultez Erreurs communes.

API

L'URL de base de tous les endpoints ci-dessous est https://cma.weegloo.com/v1, et l'en-tête Authorization doit contenir un jeton Bearer authentifiant auprès de CMA. La modification d'un rôle (PUT, PATCH) exige d'envoyer aussi l'en-tête X-Weegloo-Version (le sys.version actuel de la ressource) pour le contrôle de concurrence optimiste. La création et la suppression n'utilisent pas cet en-tête.

Documents liés

• ServiceUser : le membre inscrit qui reçoit ce rôle (roleOverride).
• ServiceLogin : désigne un ServiceUserRole comme rôle par défaut (defaultRole).
• SpaceRole : ensemble de permissions pour Weegloo User (même structure de carte de permissions).