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, publier) 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éé). 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). Elle définit, action par action, les droits de lecture, création, modification, suppression et publication des Content Type.
• 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, on n'y place donc généralement que Execute.

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 et media sont chacune une carte dont les clés sont des actions. Les actions utilisables sont Create (création), Read (lecture), Edit (modification), Delete (suppression), Publish (publication), Unpublish (dépublication), Archive (archivage) et Unarchive (désarchivage), avec aussi All qui désigne toutes les actions à la fois. Save a le même sens que Edit. La valeur de chaque action est un objet contenant les tableaux de règles Allow (autorisation) et Deny (refus). Cette structure de carte de permissions est identique à celle de SpaceRole.

"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 la liste des actions, 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. Un exemple qui restreint la modification aux seuls Content créés par soi-même à l'aide de :self est présenté plus bas, dans le bloc de modification.

La liste des actions (Create, Read, Edit, Save, Delete, Publish, Unpublish, Archive, Unarchive, All), 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 ».

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, la seule action réellement utile dans script est 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).