ServiceUserRole

Dernière mise à jour : 3 juillet 2026

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

Sa place 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 et media 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": [] } }
}

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

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

PropriétéTypeDescription
idstringIdentifiant unique de la ressource.
typestringType de ressource. Pour ServiceUserRole, toujours "ServiceUserRole".
spaceRefer<Space>Le Space auquel appartient ce ServiceUserRole.
createdByRefer<User>Utilisateur qui a créé la ressource.
createdAtstring (date-time)Date de création.
updatedByRefer<User>Dernier utilisateur ayant modifié la ressource.
updatedAtstring (date-time)Date de la dernière modification.
versioninteger (≥1)Version de la ressource. Augmente de 1 à chaque modification.

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 sont Read (lecture), Create (création), Edit (modification), Delete (suppression) et Publish (publication), avec aussi All qui désigne toutes les actions à la fois. 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.

  • contentType : limite la cible de la règle à un seul Content Type précis. 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.

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 ne sont que les trois suivantes : contentType, content et media. 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 (Read, Create, Edit, Delete, Publish, All), les clés de filtre (contentType, createdBy, tag) et le sens de :self suivent la définition des règles de permissions weegloo-space-role. Pour ServiceUserRole, :self se résout en « seulement ce qu'a créé le ServiceUser actuel ».

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.

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