#184 [Mejora] Invitación y recuperación autónoma de acceso; cambio administrativo de correo sin perder historial
Necesidad aprobada
El administrador hoy debe inventar y comunicar contraseñas. CONSOF requiere administrar el acceso sin conocer ni repartir contraseñas de usuarios.
Flujo requerido
- Crear una cuenta habilitada para login envía al correo registrado una invitación con nombre de usuario y enlace temporal de un solo uso para que el destinatario defina su contraseña. No enviar contraseñas en texto plano ni mostrarlas al administrador.
- Permitir reenviar invitación e informar su estado y errores de envío.
- Ofrecer “Olvidé mi contraseña” desde el ingreso: recuperación autónoma mediante enlace temporal de un solo uso al correo registrado. Sin revelar a terceros si existe una cuenta.
- El administrador autorizado puede solicitar restablecimiento y bloquear acceso sin borrar identidad ni historial. Bloquear debe impedir el uso de sesiones existentes conforme al mecanismo de sesiones del ERP.
- Solo el superadministrador puede cambiar el correo dentro de este flujo: conservar ID, nombre de usuario independiente, tareas, relaciones, permisos e historial; no crear cuenta nueva ni cambiar contraseña por ese solo hecho. Registrar autor/fecha del cambio, dirigir futuras comunicaciones al nuevo correo e invalidar enlaces pendientes asociados al anterior.
- Nunca recuperar o visualizar la contraseña actual. El campo vacío en edición conserva la contraseña; mantener la explicación que ya aparece.
Verificación inicial
Existe acción administrativa “Resetear contraseña”; no se probó su ejecución. En el ingreso inspeccionado no se vio recuperación autónoma. El cierre del #77 dejó pendiente verificar recuperación o trasladarla a un issue específico: este issue recoge ese pendiente y el flujo aprobado, reutilizando lo existente.
No duplicar la depuración de identidades/perfiles del #94. Personas sin login no reciben invitación automática.
Aceptación
Probar invitación, reenvío, recuperación, enlaces vencidos/usados, fallo de correo, cambio de correo, bloqueo de acceso y conservación de relaciones. Indunova debe identificar lo ya implementado y completar lo faltante. No enviar mensajes de prueba a usuarios reales.
Comentarios (9)
🤖 Pre-análisis automático (NOVA) — 🟡 falta información
¡Gracias por reportarlo! Para poder atender su solicitud correctamente y a la primera, necesitamos aclarar algunos puntos. ¿Nos ayuda respondiendo aquí mismo?
Además, nos ayudaría mucho que adjunte lo siguiente:
- Captura de pantalla o URL del módulo de ingreso actual donde no se ve la recuperación autónoma.
- Captura de pantalla o URL de la acción administrativa 'Resetear contraseña' existente.
- Texto exacto de la explicación que ya aparece junto al campo de contraseña en edición.
- Documentación o especificación del mecanismo de sesiones del ERP para asegurar que el bloqueo de acceso impida el uso de sesiones existentes.
Respuesta de CONSOF — rutas y alcance técnico
- Ingreso: https://consof-rvfp6uj2va-uc.a.run.app/ es la entrada del ERP; en una sesión no autenticada conduce al formulario de acceso. En la revisión realizada aparecían Usuario, Contraseña e Iniciar Sesión, sin enlace visible de recuperación. Se indica la entrada conocida, no una ruta de recuperación inferida.
- Acción administrativa existente: Config → Usuarios (https://consof-rvfp6uj2va-uc.a.run.app/accounts/list/) → “Resetear contraseña”. Ejemplo de enlace existente: https://consof-rvfp6uj2va-uc.a.run.app/accounts/2/reset-password/ . No ejecutarlo sobre Juan como prueba.
- Texto exacto en edición: “Dejar vacio para no cambiar la contrasena.” Se verificó en https://consof-rvfp6uj2va-uc.a.run.app/accounts/2/edit/ . Ese comportamiento se conserva; no se solicita mostrar contraseñas existentes.
- Mecanismo de sesiones: no tenemos una especificación técnica adicional de CONSOF. Identificar cómo maneja actualmente las sesiones el ERP corresponde a Indunova, sobre su implementación. La condición funcional ya aprobada es que bloquear una cuenta impida nuevos ingresos y el uso de sesiones previamente abiertas en solicitudes posteriores, sin borrar identidad ni historial. Reutilizar el mecanismo existente y documentar su validación; no necesitamos escoger internamente una tecnología de sesiones para definir ese resultado.
La invitación y recuperación deben usar enlaces temporales de un solo uso, no enviar contraseñas. No se solicita probar cambios de correo, bloqueos ni restablecimientos sobre usuarios reales.
Reforzando la necesidad de este issue: David reportó en sesión de trabajo que al editar un usuario existente, la contraseña se borra. Esto confirma que el manejo actual de contraseñas por parte del administrador es frágil y respalda directamente el flujo pedido acá (invitación por correo con enlace de un solo uso, sin que el administrador tenga que inventar/conocer/reescribir contraseñas). Dejarlo registrado como evidencia adicional para la implementación.
🔁 Devuelto por Andrea — no quedó validado.
ejecutar
— Andrea vía NOVA
Entrega #184: Invitación y recuperación de acceso sin repartir contraseñas
Estado: 🟡 en producción (revisión consof-00199-c8t). Los envíos por correo esperan a que se configure el buzón de salida (ver Pendiente).
Qué había y qué se completó
Ya existían la acción «Resetear contraseña» (el administrador escribe la clave) y el bloqueo de usuario. No había invitación, ni recuperación por cuenta propia, ni registro de envíos. Se completó lo que faltaba reutilizando lo que había.
| # | Pedido | Estado | Evidencia |
|---|---|---|---|
| 1 | Al crear una cuenta con login se envía una invitación con el usuario y un enlace temporal de un solo uso; nunca una contraseña | 🟡 | Al crear el usuario, la contraseña queda opcional («Déjela vacía para enviar una invitación…»). El correo lleva el usuario y el enlace; el enlace vence a las 72 h y sirve una sola vez |
| 2 | Reenviar la invitación y ver su estado y sus errores | 🟡 | Nueva sección Acceso en el detalle del usuario: botón «Reenviar invitación» o «Enviar enlace de restablecimiento» y tabla de envíos con fecha, tipo, destino, estado (Enviado/Error con el motivo) y quién lo pidió |
| 3 | «Olvidé mi contraseña» desde el ingreso, sin revelar si la cuenta existe | 🟡 | Respuesta idéntica exista o no el correo. Oculto mientras no haya buzón de salida (hoy /accounts/recuperar/ avisa que aún no está habilitada) |
| 4 | El administrador pide el restablecimiento y bloquea el acceso sin borrar la cuenta; el bloqueo corta las sesiones abiertas | 🟡 | Bloquear cierra las sesiones abiertas de esa persona y anula sus enlaces; la cuenta, sus permisos y su historial quedan intactos |
| 5 | Solo el superadministrador cambia el correo, sin crear otra cuenta ni cambiar la contraseña; queda quién y cuándo; los enlaces del correo anterior dejan de servir | 🟡 | Para los demás administradores el correo aparece bloqueado en la edición. Cada cambio queda en «Cambios de correo» del detalle. Los enlaces pendientes se anulan solos al cambiar el correo |
| 6 | Nunca mostrar la contraseña; si el campo queda vacío al editar, se conserva; se mantiene la explicación | 🟡 | Se mantiene «Dejar vacío para no cambiar la contraseña». Corregido además lo que reportó David: el navegador rellenaba la clave guardada del administrador al editar a otro usuario y se la cambiaba. Los campos ahora piden contraseña nueva y el navegador ya no los autocompleta |
| 7 | Enlaces vencidos o usados, fallo de correo, personas sin login | 🟡 | Enlace usado o vencido: «Este enlace ya no es válido» y opción de pedir otro. Un fallo de correo queda como Error con el motivo. Las personas sin login no reciben invitación |
| Ciberseguridad | ⚠️ | 🟡 | La clave del buzón de salida irá en el gestor de secretos, no en el código ni en la configuración visible |
Mi perfil: el usuario ya no puede cambiar su propio correo (punto 5); lo hace un superadministrador.
Pruebas
- 15 pruebas automáticas que cubren cada caso de aceptación del issue: invitación, reenvío, recuperación, enlace usado, enlace vencido, fallo de correo, cambio de correo, bloqueo con sesión abierta y conservación de relaciones. Todas en verde. PR #309.
- En producción se revisó la pantalla de ingreso, la recuperación (aviso mientras no hay correo), la sección Acceso, la edición y la creación. No se envió ningún correo ni se bloqueó o modificó ningún usuario real.
Pendiente para quedar completo
- ⏸ Buzón de salida. Falta definir desde qué correo salen las invitaciones (por ejemplo
noreply@consof.com.co) y configurarlo. Mientras tanto, las invitaciones quedan registradas como «Error: el correo saliente del ERP no está configurado» y la recuperación no se muestra. Mientras no haya buzón se puede seguir creando usuarios con contraseña escrita por el administrador.
❓ Pregunta para ti, de Andrea (Indunnova)
pendiente integracion de correo para poder valdiar
Puedes responder aquí mismo, en tu ticket.
Hola, equipo. Retomamos la validación del #184 el 6 de noviembre.
La información para la integración del correo ya fue enviada a Miguel por whatsapp el 04/11/2026 para el #320. El remitente definido es notificaciones@consof.com.co.
Hoy revisamos https://consof-rvfp6uj2va-uc.a.run.app/accounts/recuperar/ y continúa mostrando: «La recuperación por correo aún no está habilitada». Por tanto, todavía no pudimos completar la prueba de recuperación con recepción del mensaje.
Por favor, confirmen en el #320 que quedó configurado y probado el envío desde el ERP, y que se habilitó la recuperación. Con esa confirmación retomamos las pruebas del #184 con una cuenta de prueba: invitación, reenvío, recuperación y enlaces de un solo uso; luego los controles de cambio de correo, conservación del historial y bloqueo.
Esta revisión no constituye aceptación ni cierre del #184. No se modificaron contraseñas, correos ni accesos de usuarios reales. Queda identificada la dependencia de correo para continuar la validación completa.
🔁 Devuelto por Andrea — no quedó validado.
Ejecutar
— Andrea vía NOVA
🟡 Recuperación de contraseña habilitada: listos para sus pruebas del #184
David, el envío por Microsoft Graph desde notificaciones@consof.com.co quedó conectado el 8-nov y ustedes validaron la recepción en el #320 el 9-nov. Con eso ya están activos los correos de este ticket:
| # | Pedido | Estado hoy | Estado |
|---|---|---|---|
| 1 | Invitación al crear una cuenta con login (usuario + enlace de un solo uso, sin contraseña) | Activa: sale por Graph al crear el usuario con la contraseña vacía | 🟡 |
| 2 | Reenviar la invitación y ver su estado y errores | Activo en el detalle del usuario, sección Acceso | 🟡 |
| 3 | «¿Olvidó su contraseña?» desde el ingreso | Habilitado. Verificado el 10-nov: el ingreso muestra el enlace y /accounts/recuperar/ muestra el formulario (ya no dice «aún no está habilitada») |
🟡 |
| 4 | Bloquear sin borrar identidad ni historial, cortando sesiones abiertas | Sin cambios desde la entrega del 4-nov | 🟡 |
| 5 | Cambio de correo solo por superadministrador, con registro y enlaces anteriores anulados | Sin cambios desde la entrega del 4-nov | 🟡 |
| 6 | Nunca mostrar la contraseña; campo vacío la conserva | Sin cambios | 🟡 |
| Ciberseguridad | ✅ Cumple: enlaces personales de un solo uso con vencimiento; las credenciales del buzón están en el gestor de secretos | ✅ |
Por qué 🟡: no enviamos invitaciones ni recuperaciones a cuentas reales; la prueba la hacen ustedes con una cuenta de prueba, como acordamos.
Cómo probarlo (con una cuenta de prueba cuyo correo puedan abrir)
- Invitación: Config → Usuarios → Nuevo usuario, con login y contraseña vacía. Debe llegar «Invitación a CONSOF: defina su contraseña» con el usuario y el enlace. En el detalle del usuario, sección Acceso, debe verse el envío como «Enviado».
- Reenvío y enlace usado: definir la contraseña con el enlace; volver a abrir el mismo enlace debe decir «Este enlace ya no es válido». Luego «Reenviar invitación» o «Enviar enlace de restablecimiento» debe registrar otro envío.
- Recuperación: cerrar sesión → «¿Olvidó su contraseña?» → escribir el correo de la cuenta de prueba. La respuesta es la misma exista o no la cuenta; el correo llega solo si existe y está activa.
- Cambio de correo y bloqueo: con un superadministrador, cambiar el correo de la cuenta de prueba (el enlace pendiente anterior deja de servir y queda en «Cambios de correo»); bloquearla con una sesión abierta en otro navegador: esa sesión debe cerrarse en la siguiente acción.