Cómo asignar un rol a un usuario
Añade a un usuario existente un rol de acceso ya creado en organización o ubicación. La selección se prepara en la ficha del usuario y solo se aplica al guardar; no crea roles ni cambia sus permisos.
En este artículo
La asignación de roles sirve para ajustar qué puede hacer una persona dentro de Grupo Marea Demo o de una ubicación como Marea Gran Via, sin tocar el catálogo de permisos ni rediseñar el rol.
El flujo trabaja como una selección local: revisas los roles actuales del usuario, marcas un rol adicional y la aplicación crea o asegura la relación `user_roles` cuando confirmas los cambios.
Antes de empezar
- Tener sesión iniciada y una organización seleccionada.
- Para roles de ubicación, tener seleccionada la ubicación correspondiente; en el demo ES se usa Marea Gran Via.
- El usuario destino debe existir y tener membresía aceptada en la organización o ubicación.
- El rol destino debe existir previamente en el listado de roles del contexto.
- El operador necesita permisos para ver usuarios y roles, y `permissions:manage` para guardar asignaciones.
Instrucciones
- 1.
Abre la gestión de usuarios
Entra en la pestaña de usuarios de la organización o de la ubicación. Para el ejemplo principal, abre `location/access?tab=users` en Marea Gran Via.
- 2.
Selecciona el usuario
Abre la ficha del usuario al que quieres añadir el rol. La pantalla carga sus datos, los roles disponibles y los roles que ya tiene asignados.
- 3.
Revisa los roles actuales
Comprueba qué roles aparecen marcados antes de modificar nada. Si aparece `owner`, se muestra como referencia del propietario, pero no se puede asignar ni quitar desde esta acción.
- 4.
Marca el nuevo rol
Activa la casilla del rol que quieres añadir. Este gesto solo cambia la selección en pantalla; todavía no se envía ninguna petición al sistema.
- 5.
Guarda la asignación
Pulsa `Guardar cambios`. La aplicación compara la selección actual con la inicial y envía una petición por cada rol nuevo: en ubicación usa `POST /api/app/{orgId}/{locationId}/users/{userId}/roles/{roleId}` y en organización usa `POST /api/app/{orgId}/users/{userId}/roles/{roleId}`.
- 6.
Confirma el resultado
Tras una respuesta correcta, la app actualiza las listas y vuelve a la pantalla anterior con confirmación. La relación queda registrada en `user_roles` para el contexto usado.
- 7.
Usa el alta interna solo en ubicación
Como alternativa, en `location/access/users/create` puedes marcar roles antes de crear un usuario interno. La aplicación crea primero el usuario y después asigna cada rol seleccionado.
Validaciones y límites
- Si falta `selectedOrgId`, o falta `selectedLocationId` en ubicación, el flujo no puede continuar.
- La columna de selección y el guardado solo aparecen para operadores con `permissions:manage`; con permisos de consulta la tabla queda en lectura.
- Si no hay diferencias entre roles iniciales y seleccionados, el botón de guardar permanece deshabilitado.
- El identificador del rol va en la ruta `{roleId}` y el body enviado es `{}`; no se usa `role_id` en el cuerpo.
- La asignación de organización solo acepta roles válidos para la organización; la de ubicación solo acepta roles de scope `location` válidos para esa ubicación.
- El rol `owner` no es asignable desde la UI y queda fuera del delta de guardado.
- Repetir una asignación existente no duplica la relación: el repositorio la trata como idempotente.
- Crear un usuario interno desde organización no es un flujo válido; el alta interna aplica a ubicación.
Resultado esperado
El usuario queda vinculado al rol en el contexto correcto. Antylogic refresca listas, detalle de usuario, roles y sesión efectiva para reflejar los nuevos permisos cuando correspondan.