ServiceUserRole

Última actualización: 3 de julio de 2026

ServiceUserRole es un conjunto de permisos que se otorga al end-user que se ha registrado en el producto, es decir, al ServiceUser. En un único recurso reúne qué puede hacer (leer, crear, editar, eliminar, publicar) sobre Content Type, Content y Media, así como los filtros que acotan el alcance, por ejemplo solo determinados Content Type o solo lo que ha creado el propio usuario. Estos permisos se aplican a las ACMA/ACDA que invoca el ServiceUser.

Ocupa un lugar distinto del de SpaceRole. SpaceRole es el conjunto de permisos del Weegloo User (el usuario del estudio de contenidos) y se aplica a CMA/CDA, mientras que ServiceUserRole es el conjunto de permisos del ServiceUser registrado en el producto y se aplica a ACMA/ACDA. Un ServiceUserRole que se crea no se aplica por sí mismo a nadie. Se otorga asignándolo al rol predeterminado (defaultRole) de ServiceLogin o vinculándolo al roleOverride de ServiceUser.

Estructura del recurso

A continuación se muestra la respuesta de consulta individual del ServiceUserRole "Comprador". Junto con sys (propiedades del sistema), tiene las propiedades del cuerpo que definen los permisos: contentType, content y media.

{
  "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": "Comprador",
  "description": "Miembro que puede leer los productos publicados",
  "contentType": { "All": { "Allow": [] } },
  "content": {
    "Read": {
      "Allow": [
        { "contentType": { "sys": { "id": "3trmXRLdJF4GBlAjtcuoZ7Pnxj8dlA", "type": "Refer", "targetType": "ContentType" } } }
      ]
    }
  },
  "media": { "All": { "Allow": [] } }
}

Claves principales:

  • contentType: mapa de permisos sobre el propio Content Type (el esquema). Define por acción los permisos para leer, crear, modificar, eliminar y publicar Content Type.
  • content: mapa de permisos sobre Content (los datos de contenido). El ejemplo anterior muestra el caso limitado a leer únicamente el Content de un Content Type concreto.
  • media: mapa de permisos sobre Media (archivos e imágenes).

A diferencia de SpaceRole, ServiceUserRole no tiene settings para el acceso a la configuración del Space. La razón es que el ServiceUser no gestiona la configuración del Space. Tampoco tiene sys.isLocked, que indica si el recurso viene provisto de forma predefinida.

Propiedades del sistema (sys)

Todo ServiceUserRole incluye las propiedades comunes del sistema en el objeto sys. space, createdBy y updatedBy se incluyen con la forma Refer ({ "sys": { "id", "type": "Refer", "targetType" } }).

PropiedadTipoDescripción
idstringIdentificador único del recurso.
typestringTipo de recurso. Para ServiceUserRole es siempre "ServiceUserRole".
spaceRefer<Space>Space al que pertenece este ServiceUserRole.
createdByRefer<User>Usuario que lo creó.
createdAtstring (date-time)Momento de creación.
updatedByRefer<User>Último usuario que lo modificó.
updatedAtstring (date-time)Momento de la última modificación.
versioninteger (≥1)Versión del recurso. Aumenta en 1 con cada modificación.

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

Mapa de permisos: contentType, content y media

contentType, content y media son, cada uno, un mapa que tiene las acciones como claves. Las acciones son Read (leer), Create (crear), Edit (editar), Delete (eliminar) y Publish (publicar), y también existe All, que abarca todas las acciones a la vez. El valor de cada acción es un objeto que contiene los arrays de reglas Allow (permitir) y Deny (denegar). Esta estructura del mapa de permisos es la misma que la de SpaceRole.

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

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

  • contentType: limita el destino al que se aplica esa regla a un único Content Type concreto. Se incluye un Refer que apunta al Content Type.
  • createdBy: limita a los recursos creados por un usuario concreto. Si se indica un id concreto en sys.id, se limita a lo creado por esa persona; si se indica el valor reservado :self, se limita a "lo que ha creado el ServiceUser que realiza la llamada en ese momento".
  • tag: limita a los recursos que tienen un Tag concreto.

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

A diferencia de SpaceRole, ServiceUserRole no tiene settings. El mapa de permisos consta únicamente de tres elementos: contentType, content y media. Para la lista de acciones, las claves de filtro y la forma de redactar el mapa de permisos, incluido el significado de :self, consulta también la descripción de SpaceRole, que usa la misma estructura. El ejemplo de cómo acotar con :self para que solo se pueda editar el Content creado por uno mismo se muestra más abajo en el bloque de modificación.

La lista de acciones (Read, Create, Edit, Delete, Publish, All), las claves de filtro (contentType, createdBy, tag) y el significado de :self se basan en la definición de reglas de permisos de weegloo-space-role. El :self de ServiceUserRole se resuelve únicamente como lo que ha creado el ServiceUser actual.

API

La URL base de todos los endpoints siguientes es https://cma.weegloo.com/v1, y se requiere en la cabecera Authorization un token Bearer que autentique en CMA. Para modificar el rol (PUT, PATCH) hay que enviar además la cabecera X-Weegloo-Version (la sys.version actual del recurso) para el control de concurrencia optimista. La creación y la eliminación no llevan esta cabecera.

  • ServiceUser: el miembro registrado que recibe este rol (roleOverride).
  • ServiceLogin: asigna un ServiceUserRole como rol predeterminado (defaultRole).
  • SpaceRole: conjunto de permisos para Weegloo User (misma estructura de mapa de permisos).