ServiceUser
Un ServiceUser es un end-user del producto que se ha registrado mediante ServiceLogin, es decir, una cuenta de miembro. Es una identidad independiente de la cuenta de plataforma de Weegloo (el Weegloo User que inicia sesión en el estudio de contenidos), y el token de un ServiceUser se autentica frente a ACMA/ACDA.
Un ServiceUser se crea cuando el miembro se registra por sí mismo a través de ServiceLogin. Por eso esta API no tiene endpoint de creación, sino solo consulta y algunas modificaciones realizadas por un administrador (Weegloo User).
Estructura del recurso
A continuación se muestra la respuesta de consulta individual de un ServiceUser. Junto con sys (propiedades del sistema), incluye las propiedades del cuerpo nickname, avatarUrl, roleOverride y enableLogin, que contienen la información de visualización del miembro y la configuración de permisos.
{
"sys": {
"id": "3trmXRM3RqbgSnifyg7PSusr01Ex",
"type": "ServiceUser",
"space": { "sys": { "id": "HnQ32YiH", "type": "Refer", "targetType": "Space" } },
"provider": "google",
"email": "buyer@example.com",
"createdAt": "2026-06-18T12:50:00.000Z",
"updatedAt": "2026-06-18T12:50:00.000Z"
},
"nickname": "Cliente habitual",
"avatarUrl": "https://lh3.example.com/a/buyer-avatar",
"roleOverride": null,
"enableLogin": true
}Claves principales:
sys.email: la dirección de correo electrónico que el miembro usó para registrarse. Junto consys.providerindica con qué cuenta se registró.sys.provider: el proveedor de OAuth usado para el registro (por ejemplo,google).roleOverride: elReferque se incluye cuando se quiere asignar un ServiceUserRole distinto solo a este miembro. Si está vacío (null), se aplica el rol predeterminado de ServiceLogin.
Propiedades del sistema (sys)
Todo ServiceUser contiene las propiedades comunes del sistema en el objeto sys. space se incluye con la forma Refer ({ "sys": { "id", "type": "Refer", "targetType" } }).
| Propiedad | Tipo | Descripción |
|---|---|---|
id | string | Identificador único del recurso. |
type | string | Tipo de recurso. Para ServiceUser siempre es "ServiceUser". |
space | Refer<Space> | El Space al que pertenece este ServiceUser. |
provider | string | Proveedor de OAuth usado para el registro (por ejemplo, google). |
email | string | Dirección de correo electrónico usada para el registro. |
createdAt | string (date-time) | Momento del registro (creación). |
updatedAt | string (date-time) | Momento de la última modificación. |
Como un ServiceUser es un recurso que el miembro crea con su propio registro, a diferencia de otros recursos de CMA, su sys no tiene createdBy, updatedBy ni version. Como no hay version, en las modificaciones (PUT, PATCH) tampoco se envía la cabecera X-Weegloo-Version. Tampoco existe el concepto de publicación, por lo que no hay publish, archive ni status.
Propiedades del cuerpo
| Propiedad | Tipo | Descripción |
|---|---|---|
nickname | string | Nombre visible del miembro. |
avatarUrl | string | Dirección de la imagen de perfil (opcional). |
roleOverride | Refer<ServiceUserRole> | El ServiceUserRole que se asigna solo a este miembro (opcional). Si se especifica, tiene prioridad sobre el rol predeterminado de ServiceLogin. |
enableLogin | boolean | Si se permite el inicio de sesión. Al desactivarlo, se bloquea el inicio de sesión de este miembro. |
Gestión de miembros
Un ServiceUser se origina con el registro. Lo que un administrador (Weegloo User) puede ajustar mediante modificación (PUT, PATCH) son estas dos cosas:
- Asignar o quitar
roleOverride: asigna un ServiceUserRole distinto solo a un miembro concreto. Se usa cuando se quiere tratar de forma diferente a un solo miembro, como en niveles de pago, moderadores o grupos beta. ElroleOverrideasignado tiene prioridad sobre eldefaultRolede ServiceLogin. - Alternar
enableLogin: al desactivarlo, se bloquea el inicio de sesión de ese miembro.
Quitar a un miembro de la lista se hace en el estudio de contenidos. Los pasos y lo que desaparece con ello se tratan en Gestionar miembros del servicio.
Para que un miembro pueda manejar también los recursos creados por otros miembros, se crea aparte un ServiceUserRole que contenga ese permiso y se asigna al roleOverride de ese miembro. A qué accede un miembro lo determina el ServiceUserRole que se le aplica. Si en la regla se pone el filtro createdBy con :self, esa acción solo tiene por objeto lo que ha creado uno mismo; si no se pone el filtro, también tiene por objeto lo que han creado otros miembros. Cómo crear los dos roles por separado se trata en ServiceUserRole.
API
La URL base de todos los endpoints siguientes es https://cma.weegloo.com/v1, y requieren un token Bearer que autentique frente a CMA en la cabecera Authorization. Como ServiceUser es un recurso sin version, en las modificaciones (PUT, PATCH) tampoco se envía la cabecera X-Weegloo-Version. No hay endpoint de creación (se crean con el registro).
Al filtrar la consulta de la lista por sys.email, solo se usan operadores de coincidencia exacta (eq, ne, in, nin). La dirección del miembro se almacena cifrada, así que sobre esa representación solo se puede determinar si es igual o distinta: prefix o las comparaciones de orden devuelven 0 resultados sin dar error. Si busca un miembro por su dirección y el resultado viene vacío, revise primero el operador. Este filtro no sustituye a una búsqueda por una parte de la dirección.
Documentos relacionados
- ServiceUserRole: el conjunto de permisos que se asigna a
roleOverride. - ServiceLogin: registro de miembros y configuración del rol predeterminado (
defaultRole). - Visión general de ACMA/ACDA: la API que llama un ServiceUser.
- Lectura del directorio de miembros en Script: cómo buscar un miembro por id o por correo dentro de un Script y sus restricciones.
