SpaceRole

SpaceRole es un conjunto de permisos que se otorga a los miembros de un Space. En un solo recurso recoge qué se puede hacer (leer, crear, editar, eliminar, publicar) sobre Content Type, Content y Media, si se puede ejecutar y gestionar Script, y si se puede acceder a la configuración del Space. Los filtros que acotan el alcance del permiso (por ejemplo, solo ciertos Content Type, o solo lo que uno mismo ha creado) también se definen dentro del SpaceRole.

Un SpaceRole creado no se aplica a nadie por sí solo. Se otorga a un miembro añadiendo un Refer a este SpaceRole en el campo roles de Space Membership. Un mismo miembro puede tener varios SpaceRole a la vez. Además, un DeliveryAccessToken también se vincula a un único SpaceRole de least-privilege (mínimo privilegio), lo que determina el alcance de lo que ese token puede entregar.

Estructura del recurso

A continuación se muestra la respuesta de una consulta individual del SpaceRole "Producto solo lectura". Junto con sys (propiedades del sistema), tiene las propiedades de cuerpo que definen los permisos: contentType, content, media, settings y 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": "Producto solo lectura",
  "contentType": { "All": { "Allow": [] } },
  "content": {
    "Read": {
      "Allow": [
        { "contentType": { "sys": { "id": "3trmXRLdJF4GBlAjtcuoZ7Pnxj8dlA", "type": "Refer", "targetType": "ContentType" } } }
      ]
    }
  },
  "media": { "All": { "Allow": [] } },
  "settings": [],
  "script": {}
}

Claves principales:

• contentType: mapa de permisos sobre el Content Type en sí (el esquema). Define por acción los permisos para leer, crear, editar, eliminar y publicar Content Type.
• content: mapa de permisos sobre Content (los datos de contenido). El ejemplo anterior está limitado a leer únicamente el Content de un Content Type concreto.
• media: mapa de permisos sobre Media (archivos e imágenes).
• script: mapa de permisos sobre Script (endpoints de backend declarativos que llama tu frontend). Define por acción la ejecución (Execute) y la gestión (crear, leer, editar, eliminar).
• settings: array de cadenas que define el permiso de acceso a la configuración del Space. No es un mapa de permisos: enumera directamente los nombres de las acciones. El acceso total es ["SETTING_ALL"], si no se concede acceso a ninguna configuración es [], y también se pueden incluir solo las configuraciones necesarias (véase settings más abajo).
• isLocked: si es true, se trata de un rol que Weegloo proporciona de forma predeterminada (por ejemplo, Administrator) y no se puede modificar ni eliminar.

Propiedades del sistema (sys)

Todos los SpaceRole recogen propiedades del sistema comunes en el objeto sys. space, createdBy y updatedBy entran con forma Refer ({ "sys": { "id", "type": "Refer", "targetType" } }).

SpaceRole es un recurso de configuración sin concepto de publicación. Por eso, a diferencia de Content y Media, su sys no tiene publish, archive ni status, y solo tiene version. version aumenta cada vez que se modifica el SpaceRole.

Mapa de permisos: contentType, content, media

contentType, content y media son cada uno un mapa que tiene acciones como claves. Las acciones que se pueden usar son Create (crear), Read (leer), Edit (editar), Delete (eliminar), Publish (publicar), Unpublish (anular la publicación), Archive (archivar) y Unarchive (desarchivar), y también existe All, que abarca todas las acciones a la vez. No existe ninguna acción llamada Save. El permiso para modificar es Edit, y Save es el nombre de un evento al que se suscribe un Webhook. El valor de cada acción es un objeto que contiene los arrays de reglas Allow (permitir) y Deny (denegar).

"content": {
  "Read":   { "Allow": [ /* regla */ ], "Deny": [ /* regla */ ] },
  "Edit":   { "Allow": [ /* regla */ ] }
}

Cada objeto de regla (rule) tiene filtros opcionales que acotan el alcance del permiso.

• self: limita el destino al que se aplica la regla a el recurso en sí, uno solo. Se introduce un Refer que apunta al recurso de destino. En el mapa contentType significa un único Content Type concreto, y en el mapa script, un único Script concreto.
• contentType: limita al Content Type al que pertenece ese Content. Se introduce un Refer que apunta al Content Type.
• createdBy: limita a los recursos creados por un usuario concreto. Si se introduce un id de usuario concreto en sys.id, se limita solo a lo que esa persona creó; si se introduce el valor reservado :self, se limita a "solo lo creado por el usuario que llama en este momento".
• tag: limita solo a los recursos que tienen un Tag concreto.

Está fijado qué filtro tiene sentido en qué mapa de permisos. Si se introduce un filtro que no corresponde, el guardado del rol se rechaza. Si se ignorara en silencio, una regla que se creía acotada quedaría abierta a todo.

• El destino del mapa contentType se indica con self, no con contentType. Se trata de acotar el propio Content Type. El filtro contentType significa "el tipo al que hace referencia este recurso", así que solo encaja en el mapa content.
• Los filtros que intentan acotar por un eje que ese recurso no tiene (tag en Content Type, contentType en Media) no impiden el guardado, pero la regla no se evalúa como se pretendía. No los use.

Para evaluar el filtro createdBy (incluido :self) en CDA (entrega), el publishWithAuthor del Content Type de destino debe ser true. CDA evalúa este filtro con el sys.createdBy de la instantánea de publicación, así que, si publishWithAuthor tiene el valor por defecto false, la instantánea no tiene autor: la regla Allow no coincide con nada y la regla Deny no filtra a nadie. CMA (gestión) evalúa con el sys.createdBy del borrador, por lo que es independiente de esta opción. Como publishWithAuthor no es retroactivo, hay que activarlo antes de publicar el contenido, y los Content ya publicados deben publicarse de nuevo. Consulta la descripción de publishWithAuthor de Content Type.

Un array Allow vacío [] significa que se permite la acción sobre todo el conjunto de ese tipo. Como el filtro está vacío, no hay nada que filtrar, por lo que la acción queda abierta para todos los recursos.

Un array Deny vacío [] funciona al contrario. No significa "no denegar nada", sino que deniega todo el conjunto de ese tipo y bloquea por completo esa acción. Sigue bloqueada aunque se escriba también Allow. Dejar [] con la idea de que no hay nada que denegar produce el efecto opuesto, así que, si no quiere denegar nada, no incluya la clave Deny.

Ejemplo 1: Administrator (permisos totales, provisto por defecto)

El rol Administrator otorga un Allow vacío en la acción All de contentType, content, media y script, permitiendo así todo, y da ["SETTING_ALL"] en settings para acceder a toda la configuración del Space. Como Weegloo provee este rol por defecto, su sys.isLocked es true y no se puede modificar ni eliminar.

{
  "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": [] } }
}

Ejemplo 2: Solo lectura (únicamente un Content Type concreto)

Es un ejemplo de rol de least-privilege creado por uno mismo. Solo coloca una regla en la acción Read de content, y mediante el filtro contentType de esa regla lo limita a un único Content Type concreto. El Content Type en sí y Media quedan abiertos con All y un Allow vacío, pero los datos de contenido solo permiten leer ese único tipo. Como settings es [], no se puede acceder a la configuración del Space. Si se vincula un rol así a un DeliveryAccessToken, el token de entrega solo leerá ese alcance. El JSON de este rol es igual al de "Producto solo lectura" en la Estructura del recurso anterior.

settings (acceso a la configuración del Space)

settings no es un mapa de permisos, sino un array de cadenas. Recoge el permiso de acceso a la configuración del Space y no tiene ni Allow/Deny ni filtros. Las acciones que se incluyen en el array quedan permitidas; las que no se incluyen, no.

El acceso total es ["SETTING_ALL"], y si no se concede ningún acceso se deja como []. Si se necesita algo intermedio, se eligen e incluyen las acciones de abajo.

Los dos tipos de token tienen acciones separadas. Si solo se concede SETTING_DELIVERY_ACCESS_TOKEN, se podrá emitir un Delivery Access Token de solo lectura, pero no un Space Access Token, que también permite escribir.

A las acciones de settings solo se puede llamar desde una sesión iniciada en la consola o con un Personal Access Token. Un Space Access Token, un Delivery Access Token o un token de ServiceUser no pueden llamar a las API de esta lista, por muchas acciones que se hayan incluido en el rol.

La lista de acciones de los mapas de permisos (contentType, content, media, script), las claves de filtro (self, contentType, createdBy, tag), el significado de :self y qué filtro es válido en qué mapa se rigen por la sección Mapa de permisos: contentType, content, media anterior.

script (permisos de Script)

script es el mapa de permisos sobre Script (endpoints de backend declarativos que llama tu frontend). Su estructura es igual que la de content y media: tiene las acciones como claves y arrays de reglas Allow/Deny como valores. Las acciones que usa son las siguientes:

• Create, Read, Edit, Delete: crear, leer, editar y eliminar el recurso Script.
• Execute: ejecuta un Script (llamada a /execute). Es una acción propia de Script.
• All: la acción superior que incluye todas las anteriores.

Como Script no es un recurso que se publique, no se usan acciones de publicación como Publish/Unpublish. Los filtros de regla que se pueden usar son dos: self y createdBy.

• self: limita a un único Script concreto. Se introduce un Refer que apunta a ese Script (con targetType igual a Script).
• createdBy: limita por quien lo creó (con :self, "solo los Script creados por uno mismo").

contentType y tag son ejes que no se asocian a Script, así que, si se introducen, el guardado del rol se rechaza.

Por ejemplo, para permitir ejecutar cualquier Script pero leer solo los que uno mismo ha creado, se escribe así:

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

Al acotar con self se obtiene el permiso mínimo, que solo permite ejecutar un único Script. Es la forma de proceder cuando se da permiso de ejecución a un sistema externo, como una pasarela de pago: se abre solo la ventanilla que ese sistema va a llamar y el resto queda cerrado.

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

Si se vincula este rol a un Space Access Token, con ese token solo se ejecuta el único Script indicado. El motivo para acotar a un solo permiso de ejecución y el hecho de que la ejecución de un Script recibe delegados los permisos del autor se tratan en Semántica de ejecución, restricciones y seguridad.

Este permiso script decide "si se puede ejecutar y gestionar el recurso Script". Aparte de eso, al crear o editar un Script, en el momento de guardar el autor debe tener realmente los permisos de acción sobre Content y Media que utilizan los statements de ese Script; de lo contrario, el guardado se rechaza (consulte los errores de Script). Los detalles se tratan en Semántica de ejecución, restricciones y seguridad.

Errores

Códigos que se encuentran al trabajar con SpaceRole. Para los códigos comunes a todos los recursos, consulta Errores comunes.

API

La URL base de todos los endpoints siguientes es https://cma.weegloo.com/v1, y el header Authorization requiere un token Bearer que autentique frente a CMA. La modificación de roles (PUT, PATCH) requiere enviar también el header X-Weegloo-Version (el sys.version del recurso actual) para el control de concurrencia optimista. La creación y la eliminación no llevan este header. Los roles provistos por defecto cuyo sys.isLocked es true no se pueden modificar ni eliminar.

Documentos relacionados

• Space Membership: vincula un SpaceRole en el campo roles del miembro.
• Delivery Access Token: token de entrega que se vincula a un SpaceRole de least-privilege.
• Content Type: el Content Type al que apuntan las reglas de permisos.