Qué debe ocurrir con un formulario pendiente al cerrar sesión

Una persona empieza una nota de servicio en una tableta compartida y cierra sesión antes de enviarla. La siguiente inicia sesión y encuentra el texto pendiente. La pantalla de acceso funcionó, pero el borrador pasó de una cuenta a otra.

Define este comportamiento antes de aceptar un formulario móvil. Una especificación útil identifica a quién pertenece el borrador, explica qué elimina el cierre de sesión e incluye una prueba con dos cuentas. El ejemplo siguiente es un ejercicio de aceptación propuesto con datos ficticios, no un resultado de un cliente de Dynelink.

Identificar el estado antes de elegir la acción

Distingue el texto que solo existe en el dispositivo, un borrador guardado en la cuenta del servidor, un elemento en cola para enviarse y un envío aceptado por el servidor. Cada estado necesita mensajes distintos. Eliminar un borrador local no debería borrar silenciosamente un registro empresarial ya enviado.

Anota la cuenta y la organización asociadas a cada borrador. Incluye sus adjuntos, vistas previas y operaciones en cola. El formulario no queda completamente limpio si desaparece el texto pero una fotografía o tarea anterior sigue disponible para la siguiente cuenta.

Escribir una política explícita de cierre de sesión

Para este ejemplo de tableta compartida, elige descartar el formulario local pendiente y sus adjuntos temporales al confirmar el cierre de sesión. Muestra antes una advertencia clara y permite volver al formulario. No presentes como guardado un trabajo que se ha descartado.

Si el producto admite un borrador en el servidor vinculado a la cuenta, define un paso de guardado independiente y exige confirmar su éxito antes de prometer que podrá recuperarse. Especifica quién puede abrirlo y cuándo vence. Conservar borradores es una decisión de producto y seguridad; no debe ocurrir accidentalmente porque un dato sobreviva en el almacenamiento.

En una web móvil, MDN documenta que localStorage pertenece a un origen y persiste entre sesiones del navegador sin un vencimiento incorporado. Entrar con otra cuenta no convierte automáticamente ese almacenamiento en exclusivo de cada usuario. Pide al desarrollador que muestre cómo se aplica la política elegida.

Revisar el cierre más allá del formulario visible

La guía de sesiones de OWASP exige invalidar la sesión en el servidor al salir de una aplicación web y aborda la eliminación de datos sensibles del cliente. Comprueba por separado la limpieza del formulario y el fin del acceso. Una pantalla vacía no demuestra ninguna de las dos operaciones completas.

Si el cierre ocurre sin conexión, distingue la limpieza local de una acción del servidor aún sin confirmar. Define cómo se resolverá esa acción pendiente y pruébala al reconectar. No afirmes que terminaron todas las sesiones remotas solo porque apareció la pantalla de acceso.

Inspecciona también las tareas en cola. Para aplicaciones Android con WorkManager, la documentación oficial ofrece cancelación por ID, nombre o etiqueta y una señal de parada para tareas en ejecución. La implementación debe atenderla. Comprueba que ninguna tarea anterior adopte la identidad del siguiente usuario; cancelar no demuestra que se haya deshecho una acción en el servidor.

Ensayar el cambio entre dos cuentas

1. Entra como usuario de prueba A y escribe una nota ficticia reconocible con un adjunto inofensivo. Déjala sin enviar.
2. Inicia el cierre, lee la advertencia y cancela. Confirma que A conserva el formulario.
3. Repite y confirma el cierre de sesión. Comprueba que se completa la limpieza local acordada.
4. Entra como usuario de prueba B en el mismo dispositivo. Abre el formulario, el selector de adjuntos y los borradores recientes. Ninguno debe mostrar el material descartado de A.
5. Reinicia la aplicación y repite las comprobaciones. Reconecta si empezaste sin red; revisa si alguna tarea antigua intenta ejecutarse con la identidad de B.
6. Vuelve a entrar como A. Con esta política de descarte, el borrador local debe seguir ausente. Comprueba aparte que no se eliminaron registros previamente enviados.

Guardar evidencia que explique el resultado

Registra la versión de la aplicación, dispositivo, conectividad, estado del borrador, acción elegida y resultado observado. Usa etiquetas ficticias en lugar de tokens de sesión o datos de clientes. Pide revisar el almacenamiento y la cola correspondientes, además de la pantalla. Asigna un responsable a cada diferencia y repite la secuencia después de corregirla.

Revisa con Dynelink el flujo de tu formulario móvil para definir la pertenencia del borrador, los mensajes de cierre y las pruebas antes de entregar un dispositivo compartido a otra persona.

Ilustración conceptual generada con IA; no es una captura de un cliente.