SpaceRole

Un SpaceRole est un ensemble de permissions accordé aux membres d'un Space. Il regroupe dans une seule ressource ce qu'il est possible de faire (lire, créer, modifier, supprimer, publier) sur les Content Type, Content et Media, la possibilité d'exécuter et de gérer les Script, ainsi que l'accès aux paramètres du Space. Les filtres qui restreignent la portée des permissions (à un seul Content Type, à ce que l'on a créé soi-même, etc.) sont eux aussi définis à l'intérieur du SpaceRole.

Un SpaceRole créé ne s'applique de lui-même à personne. Vous l'attribuez à un membre en plaçant un Refer vers ce SpaceRole dans le champ roles de la Space Membership. Un même membre peut détenir plusieurs SpaceRole en même temps. Un DeliveryAccessToken est lui aussi lié à un unique SpaceRole en least-privilege (privilège minimal), ce qui détermine la portée de ce que ce token peut recevoir en distribution.

Structure de la ressource

Voici la réponse de la lecture unitaire du SpaceRole « Produit en lecture seule ». Avec sys (propriétés système), il possède les propriétés de corps qui définissent les permissions : contentType, content, media, settings et script.

{
  "sys": {
    "id": "3trmXRM3RqbgSnifyg7ObyNrQQbHbm",
    "type": "SpaceRole",
    "space": { "sys": { "id": "HnQ32YiH", "type": "Refer", "targetType": "Space" } },
    "createdBy": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } },
    "createdAt": "2026-06-16T09:53:16.617Z",
    "updatedBy": { "sys": { "id": "3p4tcFbQRwz503VXdtHXNI5dZH5TVB", "type": "Refer", "targetType": "User" } },
    "updatedAt": "2026-06-16T09:53:16.617Z",
    "isLocked": false,
    "version": 1
  },
  "name": "Produit en lecture seule",
  "contentType": { "All": { "Allow": [] } },
  "content": {
    "Read": {
      "Allow": [
        { "contentType": { "sys": { "id": "3trmXRLdJF4GBlAjtcuoZ7Pnxj8dlA", "type": "Refer", "targetType": "ContentType" } } }
      ]
    }
  },
  "media": { "All": { "Allow": [] } },
  "settings": [],
  "script": {}
}

Clés principales :

• contentType : carte de permissions sur le Content Type lui-même (le schéma). Définit, action par action, le droit de lire, créer, modifier, supprimer et publier un Content Type.
• content : carte de permissions sur le Content (les données de contenu). L'exemple ci-dessus limite la lecture au seul Content d'un Content Type précis.
• media : carte de permissions sur les Media (fichiers et images).
• script : carte de permissions sur le Script (endpoints backend déclaratifs appelés par votre frontend). Définit, action par action, l'exécution (Execute) et la gestion (créer, lire, modifier, supprimer).
• settings : tableau de chaînes qui définit le droit d'accès aux paramètres du Space. Ce n'est pas une carte de permissions : il énumère directement les noms des actions. L'accès total est ["SETTING_ALL"], [] n'accorde aucun accès aux paramètres, et vous pouvez aussi n'y placer que les paramètres dont vous avez besoin (voir settings ci-dessous).
• isLocked : si true, il s'agit d'un rôle fourni par défaut par Weegloo (par exemple Administrator), qui ne peut être ni modifié ni supprimé.

Propriétés système (sys)

Chaque SpaceRole place ses propriétés système communes dans l'objet sys. Les champs space, createdBy et updatedBy se présentent sous la forme Refer ({ "sys": { "id", "type": "Refer", "targetType" } }).

Un SpaceRole est une ressource de configuration sans notion de publication. C'est pourquoi, contrairement aux Content et Media, son sys ne comporte ni publish, ni archive, ni status, et possède seulement version. La version augmente à chaque modification du SpaceRole.

Carte de permissions : contentType, content, media

contentType, content et media sont chacun une carte ayant des actions pour clés. Les actions utilisables sont Create (créer), Read (lire), Edit (modifier), Delete (supprimer), Publish (publier), Unpublish (dépublier), Archive (archiver) et Unarchive (désarchiver), avec également All qui désigne toutes les actions à la fois. 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. La valeur de chaque action est un objet contenant les tableaux de règles Allow (autoriser) et Deny (refuser).

"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 : restreint la cible de la règle à la ressource elle-même. Vous y placez un Refer qui pointe vers la ressource visée. Dans le mappage contentType, cela désigne un seul Content Type ; dans le mappage script, un seul Script.
• contentType : restreint au Content Type auquel appartient ce Content. Vous y placez un Refer qui pointe vers le Content Type.
• createdBy : restreint aux seules ressources créées par un utilisateur précis. En renseignant l'sys.id d'un utilisateur donné, la portée se limite à ce qu'il a créé ; avec la valeur réservée :self, elle se limite à « ce que l'utilisateur appelant a créé ».
• tag : restreint aux seules ressources portant un Tag précis.

Le mappage de permissions dans lequel chaque filtre a un sens est fixé. Y placer un filtre qui ne convient pas fait refuser l'enregistrement du rôle. C'est qu'en l'ignorant silencieusement, une règle que l'on croyait restreinte deviendrait une autorisation générale.

• Dans le mappage contentType, la cible se désigne avec self et non avec contentType. C'est qu'il s'agit de restreindre le Content Type lui-même. Le filtre contentType signifie « le type que cette ressource référence » et ne convient donc qu'au mappage content.
• Un filtre qui tente de restreindre sur un axe absent de la ressource (tag sur un Content Type, contentType sur un Media) n'est pas bloqué à l'enregistrement, mais la règle n'est pas évaluée comme prévu. Ne les utilisez pas.

Pour que le filtre createdBy (y compris :self) soit évalué sur CDA (distribution), le publishWithAuthor du Content Type visé doit valoir true. CDA é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 et que les règles Deny n'écartent personne. CMA (gestion) évalue à partir du sys.createdBy du brouillon et ne dépend donc pas de ce paramètre. publishWithAuthor n'étant pas rétroactif, il doit être activé avant de publier le contenu, et les Content déjà publiés doivent être republiés. Reportez-vous à l'explication de publishWithAuthor du Content Type.

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

Un tableau Deny vide [] fonctionne à l'inverse. Il ne signifie pas « ne rien refuser » mais refuser tout le type concerné, ce qui bloque complètement l'action. Elle reste bloquée même si vous écrivez aussi un Allow. Poser [] en pensant qu'il n'y a rien à refuser produit donc l'effet exactement contraire : pour ne rien refuser, n'incluez pas du tout la clé Deny.

Exemple 1 : Administrator (toutes les permissions, fourni par défaut)

Le rôle Administrator autorise tout : il accorde un Allow vide à l'action All pour contentType, content, media et script, et donne ["SETTING_ALL"] à settings pour accéder à l'ensemble des paramètres du Space. Comme ce rôle est fourni par défaut par Weegloo, son sys.isLocked vaut true et il ne peut être ni modifié ni supprimé.

{
  "sys": {
    "id": "3trmXRLdJF4GBlAjtcuoWfVubsasp4",
    "type": "SpaceRole",
    "space": { "sys": { "id": "HnQ32YiH", "type": "Refer", "targetType": "Space" } },
    "createdBy": { "sys": { "id": "_", "type": "Refer", "targetType": "User" } },
    "createdAt": "2026-06-14T14:56:04.737Z",
    "updatedBy": { "sys": { "id": "_", "type": "Refer", "targetType": "User" } },
    "updatedAt": "2026-06-14T14:56:04.737Z",
    "isLocked": true,
    "version": 1
  },
  "name": "Administrator",
  "description": "Members of this role have full access to everything in this space.",
  "contentType": { "All": { "Allow": [] } },
  "content": { "All": { "Allow": [] } },
  "media": { "All": { "Allow": [] } },
  "settings": ["SETTING_ALL"],
  "script": { "All": { "Allow": [] } }
}

Exemple 2 : lecture seule (un seul Content Type)

Exemple d'un rôle least-privilege que vous créez vous-même. Une règle est posée uniquement sur l'action Read de content, et le filtre contentType de cette règle la limite à un seul Content Type. Le Content Type lui-même et les Media restent ouverts via All avec un Allow vide, mais pour les données de contenu, seule la lecture de ce type précis est possible. Comme settings vaut [], l'accès aux paramètres du Space n'est pas accordé. Lier un tel rôle à un DeliveryAccessToken fait que le token de distribution ne lit que cette portée. Le JSON de ce rôle est identique à celui de « Produit en lecture seule » dans la structure de la ressource ci-dessus.

settings (accès aux paramètres du Space)

settings n'est pas une carte de permissions, mais un tableau de chaînes. Il porte le droit d'accès aux paramètres du Space, sans Allow/Deny ni filtre. Les actions placées dans le tableau sont autorisées ; celles qui n'y sont pas placées ne le sont pas.

Pour l'accès total, utilisez ["SETTING_ALL"] ; pour n'accorder aucun accès, laissez []. S'il vous faut un niveau intermédiaire, choisissez parmi les actions ci-dessous.

Les deux types de token ont des actions distinctes. Si vous n'accordez que SETTING_DELIVERY_ACCESS_TOKEN, l'émission d'un Delivery Access Token en lecture seule est possible, mais pas celle d'un Space Access Token, qui va jusqu'à l'écriture.

Les actions de settings ne s'appellent qu'avec une session de connexion à la console ou un Personal Access Token. Les tokens Space Access Token, Delivery Access Token et ServiceUser ne peuvent pas appeler les API de cette liste, quelles que soient les actions placées dans leur rôle.

La liste des actions des cartes de permissions (contentType, content, media, script), les clés de filtre (self, contentType, createdBy, tag), la signification de :self ainsi que le mappage dans lequel chaque filtre est valide suivent la section Carte de permissions : contentType, content, media ci-dessus.

script (permissions du Script)

script est la carte de permissions sur le Script (endpoints backend déclaratifs appelés par votre frontend). Sa structure est identique à celles de content et media : des actions pour clés, et des tableaux de règles Allow/Deny pour valeurs. Les actions utilisées sont les suivantes.

• Create, Read, Edit, Delete : créer, lire, modifier et supprimer une ressource Script.
• Execute : exécuter un Script (appel de /execute). Action propre au Script.
• All : action de niveau supérieur qui englobe toutes les précédentes.

Comme un Script n'est pas une ressource que l'on publie, les actions de publication telles que Publish/Unpublish ne sont pas utilisées. Les filtres de règle utilisables sont self et createdBy, tous les deux.

• self : restreint à un seul Script. Vous y placez un Refer vers ce Script (son targetType est Script).
• createdBy : restreint selon le créateur (avec :self, aux « Script que l'on a créés soi-même »).

contentType et tag sont des axes qui ne s'attachent pas au Script : les y placer fait refuser l'enregistrement du rôle.

Par exemple, pour autoriser l'exécution de tous les Script tout en limitant la lecture à ceux que l'on a créés soi-même, procédez ainsi.

"script": {
  "Execute": { "Allow": [] },
  "Read": {
    "Allow": [
      { "createdBy": { "sys": { "id": ":self", "type": "Refer", "targetType": "User" } } }
    ]
  }
}

Restreindre avec self donne la permission minimale : un seul Script exécutable. C'est la manière, lorsqu'on accorde un droit d'exécution à un système extérieur comme un prestataire de paiement, de n'ouvrir que le guichet que ce système va appeler et de laisser tout le reste fermé.

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

En liant ce rôle à un Space Access Token, ce jeton n'exécute que le Script désigné. La raison de se restreindre à un seul droit d'exécution, ainsi que le fait que l'exécution d'un Script s'appuie sur les permissions déléguées de son auteur, sont traités dans Sémantique d'exécution, contraintes et sécurité du Script.

Cette permission script détermine « peut-on exécuter et gérer la ressource Script ». Indépendamment de cela, lorsque vous rédigez un Script (le créer ou le modifier), l'auteur doit, au moment de l'enregistrement, détenir effectivement les permissions d'action sur les Content/Media que manipulent les statements de ce Script ; sinon l'enregistrement est refusé (voir Erreurs du Script). Pour en savoir plus, consultez Sémantique d'exécution, limites et sécurité du Script.

Erreurs

Ce sont les codes que l'on rencontre lorsque l'on manipule un SpaceRole. 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 un token Bearer authentifiant CMA est requis dans l'en-tête Authorization. La modification d'un rôle (PUT, PATCH) exige aussi l'envoi de l'en-tête X-Weegloo-Version (la sys.version actuelle de la ressource) pour le contrôle de concurrence optimiste. La création et la suppression n'ont pas cet en-tête. Les rôles fournis par défaut dont sys.isLocked vaut true ne peuvent être ni modifiés ni supprimés.

Documents liés

• Space Membership : lie un SpaceRole au champ roles d'un membre.
• Delivery Access Token : token de distribution lié à un SpaceRole en least-privilege.
• Content Type : le Content Type que pointent les règles de permission.