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) 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. Las acciones que se pueden usar varían según el mapa (véase la tabla de Mapa de permisos más abajo). 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). El ServiceUser solo lee el formulario, así que únicamente se define Read.
• 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.

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, media y script son, cada uno, un mapa que tiene las acciones como claves. El valor de cada acción es un objeto que contiene los arrays de reglas Allow (permitir) y Deny (denegar). La estructura del mapa es la misma que la de SpaceRole, pero las acciones que se pueden usar varían según el mapa y son más limitadas que en SpaceRole.

All abarca a la vez todas las acciones que se pueden usar en ese mapa. Si se pone como clave una acción que no está en la tabla, el guardado del rol se rechaza. Las acciones de publicación (Publish, Unpublish, Archive, Unarchive) no están en ningún mapa porque el Content y el Media que crea un miembro se publican en el mismo momento en que se crean (véase ACMA).

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.

"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 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. Ahora bien, las acciones que se pueden usar son las de la tabla anterior y no coinciden con las de SpaceRole. El ejemplo de cómo acotar con :self para que solo se pueda editar el Content creado por uno mismo se muestra justo debajo, en Rol de miembro general y rol de administrador.

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. La lista de acciones no sigue a SpaceRole, sino la tabla anterior.

Rol de miembro general y rol de administrador

Que un miembro pueda manejar también los recursos de otros miembros se decide con el filtro createdBy de la regla. Aun tratándose de la misma acción, si en createdBy se pone :self, esa acción solo tiene por objeto lo que ha creado el miembro que realiza la llamada; si no se pone createdBy, también tiene por objeto lo que han creado otros miembros.

El rol que se otorga a un miembro general limita Edit y Delete con :self.

"content": {
  "Edit": {
    "Allow": [
      {
        "contentType": { "sys": { "id": "3trmXRLdJF4GBlAjtcuoZ7Pnxj8dlA", "type": "Refer", "targetType": "ContentType" } },
        "createdBy": { "sys": { "id": ":self", "type": "Refer", "targetType": "User" } }
      }
    ]
  },
  "Delete": {
    "Allow": [
      {
        "contentType": { "sys": { "id": "3trmXRLdJF4GBlAjtcuoZ7Pnxj8dlA", "type": "Refer", "targetType": "ContentType" } },
        "createdBy": { "sys": { "id": ":self", "type": "Refer", "targetType": "User" } }
      }
    ]
  }
}

Al miembro que vaya a ejercer de administrador se le crea aparte un rol en el que se quita createdBy de esas mismas acciones. El siguiente es un rol que abre solo el borrado a lo de otros miembros y deja la edición limitada a lo propio.

"content": {
  "Edit": {
    "Allow": [
      {
        "contentType": { "sys": { "id": "3trmXRLdJF4GBlAjtcuoZ7Pnxj8dlA", "type": "Refer", "targetType": "ContentType" } },
        "createdBy": { "sys": { "id": ":self", "type": "Refer", "targetType": "User" } }
      }
    ]
  },
  "Delete": {
    "Allow": [
      { "contentType": { "sys": { "id": "3trmXRLdJF4GBlAjtcuoZ7Pnxj8dlA", "type": "Refer", "targetType": "ContentType" } } }
    ]
  }
}

El rol creado así se asigna al roleOverride de ServiceUser para aplicarlo solo a ese miembro. Si se deja el rol de miembro general como defaultRole de ServiceLogin, los miembros que se registren a partir de entonces no reciben el rol de administrador.

Con Media funciona igual. Si se quita createdBy de las acciones del mapa media, también entran en el alcance los archivos subidos por otros miembros. Ahora bien, el filtro contentType solo se usa en el mapa content, así que no se incluye en el mapa media.

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 el script de un ServiceUserRole solo se pueden usar dos acciones: All y 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).