ServiceUserRole

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, si puede ejecutar un Script, 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.

ServiceUserRole 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, media y script.

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

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).
• script: mapa de permisos sobre Script (endpoints de backend declarativos). El ServiceUser solo ejecuta (Execute) un Script, por lo que normalmente solo se establece Execute.

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

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 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. Save significa lo mismo que Edit. 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.

• self: limita el destino al que se aplica esa regla a el recurso en sí, uno solo. 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 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.

Qué filtro es válido en qué mapa de permisos es igual que en SpaceRole (el mapa contentType indica su destino con self y el mapa content, con contentType), y si se incluye un filtro que no corresponde, el guardado del rol se rechaza. La tabla por mapas está en el mapa de permisos de SpaceRole.

Para aplicar el filtro createdBy (incluido :self) en ACDA, el publishWithAuthor del Content Type de destino debe ser true. ACDA 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 (el miembro recibe sus propios recursos como un resultado vacío) y la regla Deny no filtra a nadie. En cambio, ACMA (gestión) evalúa con el sys.createdBy del borrador, por lo que es independiente de esta opción; así, una misma regla puede funcionar en ACMA pero desajustarse en ACDA. publishWithAuthor debe activarse antes de que el miembro publique su contenido y no es retroactivo. Consulta la descripción de publishWithAuthor de Content Type.

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 de cuatro elementos: contentType, content, media y script. 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 (Create, Read, Edit, Save, Delete, Publish, Unpublish, Archive, Unarchive, All), las claves de filtro (self, contentType, createdBy, tag) y el significado de :self se basan en la definición de reglas de permisos de SpaceRole. El :self de ServiceUserRole se resuelve únicamente como lo que ha creado el ServiceUser actual.

script (permisos de Script)

script es el mapa de permisos sobre Script; su estructura es la misma que la de content y media. Sin embargo, lo único que un ServiceUser puede hacer con un Script es ejecutarlo (la autoría, es decir crear/editar/eliminar, es exclusiva de CMA / Weegloo User). Por eso, en un ServiceUserRole la única acción que se usa de forma efectiva en script es Execute.

Para que un miembro registrado pueda ejecutar un Script, se escribe así:

"script": {
  "Execute": { "Allow": [] }
}

Como filtros de regla se pueden usar dos: self (un único Script concreto) y createdBy. contentType y tag son ejes que no se asocian a Script, así que, si se incluyen, el guardado del rol se rechaza. Para permitir que un miembro ejecute únicamente un Script concreto, se pone en el Allow de Execute una regla self que apunte a ese Script.

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

La estructura del propio Script y su endpoint de ejecución se tratan en Recurso Script y endpoints; la lista completa de acciones se trata en el permiso script de SpaceRole.

Errores

Códigos que se encuentran al trabajar con ServiceUserRole. 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 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.

Documentos relacionados

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