Users: cuentas, estado y acceso inicial
Objetivo y permisos
Users administra cuentas dentro del alcance delegado. La navegación requiere admin.users.view; crear y modificar requiere admin.users.manage. Ver cuentas no autoriza cambiar roles. Confirme tenant y rol activo antes de abrir New user. No conceda capacidades adicionales por comodidad durante un diagnóstico.
Campos y decisiones
| Elemento | Decisión administrativa |
|---|---|
| Name | Nombre identificable, sin contraseñas ni notas sensibles |
| Dirección válida controlada por el destinatario | |
| Tenant | Workspace dentro del alcance delegado |
| Estado | Opción correspondiente al ciclo de la cuenta |
| Grupo/permisos y roles | Capacidades mínimas según opciones permitidas |
| Método de primer acceso | Mecanismo de activación ofrecido |
No todas las opciones se aplican a todas las cuentas. Una identidad externa y una cuenta local pueden tener acciones diferentes. La UI contempla emisión y revocación de activaciones, conversión a acceso local y restauración de SSO en contextos específicos; no son operaciones intercambiables.
Alta controlada
- Abra Users y busque la dirección antes de crear otra cuenta. Evite duplicar una identidad por una invitación pendiente.
- Seleccione New user, complete nombre y email, y elija el tenant correcto.
- Asigne sólo roles necesarios. Relacione cada permiso con una tarea concreta.
- Seleccione estado y método de primer acceso disponible. Revise antes de confirmar.
- Tras guardar, compruebe cuenta y estado en el inventario. Creación correcta no prueba recepción o uso de la activación.
Los enlaces de activación son de un solo uso. Emitir uno nuevo revoca el anterior según el flujo. No copie enlaces a documentación, tickets públicos ni capturas. Ante fallo de entrega revise transporte y operación administrativa antes de emitir repetidamente invitaciones.
Caso de uso y POC sintético
Prepare en un entorno aislado analista.demo@example.test, vinculada a laboratorio-documentacion. El objetivo es permitir lectura necesaria sin administración de workers. Cree previamente el rol adecuado, asigne la cuenta y verifique opciones con una sesión de prueba autorizada. Incluya tanto una lectura permitida como una acción administrativa no disponible o rechazada.
example.test es ilustrativo: no sirve como destinatario real para comprobar entrega. Si prueba correo, utilice un buzón de laboratorio controlado y no publique su configuración. La evidencia debe mostrar el resultado del acceso, nunca secretos del primer inicio.
Errores y recuperación
Corrija campos incompletos antes de enviar; email tiene formato validado y tenant es obligatorio. Un error de autorización exige revisar el rol activo, no elevar automáticamente permisos de la cuenta objetivo. Si su estado cambió en paralelo, recargue y compare antes de editar.
Para una identidad SSO diagnostique proveedor y política primero. Convert to local access cambia el mecanismo de inicio; no reenvía simplemente un email. Restore SSO access elimina el bloqueo de activación local en casos soportados conservando tenants y roles. Registre motivo y verifique estado después. Cerrar el diálogo descarta interacción local, pero no deshace una petición ya confirmada.
Una revisión periódica debe comprobar que las capacidades siguen respondiendo al trabajo de la persona. Al retirar acceso, use las acciones autorizadas y conserve trazabilidad. No comparta una cuenta administrativa para evitar crear identidades individuales: impediría atribuir correctamente operaciones.