US-049 — Gestión de usuarios

Detalle de la historia¶

Historia¶

Como administrador de FleteChat, quiero crear, editar y desactivar usuarios del backoffice, asignarles rol y gestionar su contraseña, para mantener el equipo operativo al día sin depender del equipo técnico cada vez que entra o sale alguien.

Persona de usuario¶

Aplica exclusivamente al rol admin. Otros roles no gestionan usuarios.

Contexto de negocio¶

Un equipo operativo cambia: gente entra, cambia de función, sale. Tenerlo bajo control del admin del backoffice —y no de un script o del equipo técnico— es lo que permite reaccionar a la realidad del negocio. La gestión incluye alta, edición de datos básicos (nombre, email), asignación de rol (ver historia de control de acceso), desactivación, y acciones sobre la sesión (forzar cierre, resetear contraseña, desbloquear tras bloqueo por intentos fallidos).

El principio de "al menos un admin siempre activo" (ver PR-190) protege contra quedar sin quien gestionar el sistema. La UI y el backend bloquean cualquier acción que lo violaría.

Criterios de aceptación¶

Alta¶

1. El admin puede crear un usuario nuevo ingresando: nombre completo, email (único, no distingue mayúsculas), rol (admin, operator, price_manager; ver US-047), estado (activo por defecto).
2. Al crear, el sistema envía al email del nuevo usuario un enlace firmado de un solo uso para que defina su contraseña inicial (reutiliza el mecanismo de recuperación de US-048). El usuario no queda operativo hasta definir contraseña.
3. El email es único en el sistema; el admin recibe error si intenta crear con email ya existente (activo o desactivado).

Edición¶

1. El admin puede editar nombre y rol de un usuario. El email no es editable en v1.0 (un cambio de email equivale a crear usuario nuevo y desactivar el anterior) para preservar trazabilidad del audit log.
2. Cambiar el rol queda auditado con actor, timestamp, rol anterior y rol nuevo. El nuevo rol aplica en el siguiente login del usuario (ver PR-186 de US-047).

Desactivación y reactivación¶

1. El admin puede desactivar un usuario. Un usuario desactivado no puede iniciar sesión (ver US-048 edge cases); sus sesiones activas se cierran automáticamente al desactivar.
2. El admin puede reactivar un usuario desactivado; al reactivar, el usuario puede volver a iniciar sesión con su contraseña existente (no se resetea automáticamente).
3. Nunca se puede desactivar al último admin activo del sistema (ver PR-190); la UI y el backend rechazan la acción con mensaje claro.
4. El admin no puede desactivarse a sí mismo (ver PR-191): evita cierres accidentales. Para desactivar al admin actual, otro admin debe hacerlo.

Acciones sobre la cuenta¶

1. El admin puede resetear la contraseña de un usuario: el sistema envía un nuevo enlace firmado al email del usuario y revoca enlaces anteriores.
2. El admin puede desbloquear un usuario bloqueado por intentos fallidos (ver PR-188 de US-048), restaurando la posibilidad de intentar login.
3. El admin puede forzar el cierre de todas las sesiones activas de un usuario; útil cuando hay sospecha de sesión comprometida o cambio de rol que debe aplicar inmediato.

Audit log¶

1. Cada alta, edición, cambio de rol, desactivación, reactivación, reset de contraseña, desbloqueo y cierre forzado queda registrada en el audit log con actor (admin), timestamp, usuario afectado y diff.

Edge cases¶

• Admin intenta degradarse a operator siendo el único admin. Rechazado: dejaría el sistema sin admin (ver PR-190). Mensaje explica cómo asignar admin a otro usuario antes.
• Admin desactiva un usuario con sesiones activas. Las sesiones se cierran inmediatamente; el usuario ve la página de login la próxima vez que intente una acción.
• Email con mayúsculas o con espacios sobrantes. El sistema normaliza (minúsculas, trim) antes de guardar y validar unicidad.
• Admin reactiva un usuario cuyo rol asignado fue desactivado del sistema (v1.0 no contempla esto porque los roles son fijos; pero si ocurre por cambio futuro, el sistema pide reasignar rol antes de reactivar).
• Creación masiva de usuarios. v1.0 no soporta import masivo; el admin crea uno a la vez. Se evalúa para versiones posteriores si el volumen lo justifica.

Tamaño, prioridad y tipo¶

• Tamaño: M
• Prioridad: P0 — sin gestión de usuarios el backoffice no tiene cómo dar de alta al equipo operativo.
• Tipo: feature

Premisas¶

La historia está redactada bajo las siguientes premisas. Si alguna cambia, la historia debe revisarse y ajustarse en consecuencia. Todas deben ser confirmadas por el cliente antes de cerrar la historia.

• PR-190 — Al menos un admin activo siempre. El sistema nunca permite dejar cero admins activos. Desactivar o degradar el último admin es rechazado por UI y backend.
• PR-191 — Admin no se desactiva a sí mismo. Un admin no puede ejecutar desactivación ni degradación sobre su propio usuario. Otro admin debe hacerlo para prevenir cierres accidentales.
• PR-224 — Cierre forzado de sesiones al cambiar rol o desactivar usuario. Toda acción administrativa que altera los permisos efectivos de un usuario (cambio de rol, desactivación, degradación) ofrece al admin la opción de forzar el cierre inmediato de todas las sesiones activas del usuario afectado; por defecto la opción está marcada como activa para desactivaciones y para degradaciones, y desactivada para cambios entre roles operativos (admin↔operator↔price_manager sin reducción de capacidades sensibles). El admin puede desmarcar con justificación. Al forzar el cierre, el usuario es deslogueado inmediatamente del backoffice y en el siguiente acceso enfrenta el nuevo rol. La alternativa (dejar que PR-186 aplique en el siguiente login) sigue siendo válida cuando el admin lo considere seguro. Cada cierre forzado queda en audit log como evento separado con actor, motivo y cantidad de sesiones cerradas.

Refinamiento y Definition of Ready¶

Notas¶

Checklist¶

• ✅ Historia escrita en formato Como / Quiero / Para
• ✅ Persona de usuario identificada
• ✅ Contexto de negocio documentado
• ✅ Criterios de aceptación observables y pass/fail
• ✅ Edge cases relevantes listados
• ✅ Tamaño y prioridad asignados
• ⬜ Premisas PR-190, PR-191 y PR-224 confirmadas por el cliente
• ⬜ Reglas de negocio aplicables aprobadas
• ⬜ Requerimientos funcionales aplicables aprobados
• ⬜ Historia aprobada formalmente por el cliente