US-046 — Parámetros globales del sistema

Detalle de la historia¶

Historia¶

Como administrador de FleteChat, quiero configurar los parámetros globales del sistema (vigencia de cotizaciones, expiración de enlaces, ventana de aviso de vencimiento corporativo, umbrales, horarios, etc.) desde el backoffice, para ajustar el comportamiento operativo sin tocar código.

Persona de usuario¶

Aplica exclusivamente al rol admin. Los parámetros impactan a operadores, clientes y procesos automáticos, pero su gestión está centralizada en admin para mantener trazabilidad y evitar divergencia operativa.

Contexto de negocio¶

A lo largo del análisis, muchas historias mencionan parámetros configurables: vigencia de cotizaciones (PR-121 de US-028 no; ver US-014), ventana del enlace a vista web (PR-127), vida del código OTP (PR-149), timeout de desconexión del operador (PR-151), umbral para volumen alto (PR-121 de US-028), ventana de aviso corporativo (PR-162), ventana de horario razonable (PR-197), y muchos otros. Dispersarlos en archivos de configuración de código significa pedirle al equipo técnico cada ajuste; centralizarlos en una UI del backoffice los vuelve accionables para el admin.

Los parámetros afectan comportamiento futuro del sistema: cambiar "vigencia de cotización" de 48h a 72h no extiende cotizaciones ya emitidas, aplica a las nuevas (ver PR-181). Cada cambio queda auditado para responder a preguntas del tipo "¿por qué esta cotización venció a las 72h y la anterior a las 48h?".

Criterios de aceptación¶

Acceso y organización¶

1. El backoffice ofrece una sección "Parámetros del sistema" accesible exclusivamente al rol admin. Otros roles reciben 403.
2. Los parámetros se agrupan por dominio (cotización, enlaces, handoff, notificaciones, reportes, corporativos, horarios, etc.) para que el admin los encuentre rápidamente. Cada parámetro tiene: clave (único, legible), nombre, descripción, tipo (entero, duración, booleano, texto, lista enumerada), valor actual, valor por defecto, rango/validaciones.

Edición¶

1. El admin puede editar el valor de un parámetro desde la UI. La UI valida el tipo y el rango antes de guardar; valores fuera de rango se rechazan con mensaje claro.
2. Cada cambio pide confirmación explícita con un resumen del impacto esperado (por ejemplo, "este cambio afectará a cotizaciones emitidas desde ahora").
3. Parámetros críticos (identificados en el catálogo de parámetros) requieren además motivo obligatorio del cambio (texto libre breve) que queda en el audit log.

Efecto temporal¶

1. Los cambios aplican a nuevas entidades creadas tras el cambio; entidades ya emitidas (cotizaciones, enlaces, asignaciones) mantienen el valor vigente al momento de su creación como snapshot (ver PR-181).
2. Parámetros puramente operativos que no se snapshotean (por ejemplo, el timeout de desconexión del operador) aplican inmediatamente al cambiar; los cambios quedan documentados en el audit log.

Reset y versionamiento¶

1. Cada parámetro muestra su valor por defecto y permite al admin restaurar ese valor con confirmación.
2. El admin puede consultar el historial de cambios del parámetro directamente desde la UI, ordenado cronológicamente con actor, valor anterior, valor nuevo y motivo si fue requerido.

Audit log¶

1. Cada edición queda registrada en el audit log con actor (admin), timestamp, clave del parámetro, valor anterior, valor nuevo y motivo (cuando aplica). El audit log nunca se borra (ver PR-182).

Edge cases¶

• Admin cambia la vigencia de cotización de 48h a 24h. Las cotizaciones ya emitidas mantienen su vencimiento original; las nuevas usan el nuevo valor. La UI avisa claramente que el cambio no retrocede.
• Admin restaura un parámetro al default. Equivale a editar el parámetro a su valor por defecto; pasa por las mismas validaciones, auditorías y confirmaciones.
• Admin intenta poner un valor fuera de rango (por ejemplo, ventana de aviso corporativo en -5 días). La UI rechaza antes de guardar; el audit log no se ensucia con intentos inválidos.
• Parámetro eliminado del sistema en una versión posterior. Los valores históricos del audit log permanecen visibles aunque el parámetro ya no sea editable.
• Dos admins editan el mismo parámetro al mismo tiempo. El segundo en confirmar recibe un aviso de conflicto (el valor en la UI era anterior al cambio del primero); debe refrescar y confirmar con el valor actual.

Tamaño, prioridad y tipo¶

• Tamaño: M
• Prioridad: P0 — muchas historias de v1.0 dependen de parámetros configurables; sin esta UI esos ajustes requieren intervención técnica.
• 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-181 — Parámetros aplican a nuevas entidades. Cambiar un parámetro afecta el comportamiento del sistema para entidades creadas desde el cambio en adelante. Entidades ya emitidas (cotizaciones, enlaces, asignaciones) mantienen el valor vigente al momento de su creación como snapshot. Parámetros puramente operativos que no se snapshotean aplican inmediatamente.
• PR-182 — Audit log inmutable de parámetros. El audit log de parámetros nunca se borra. Cada cambio queda trazable con actor, timestamps, valores y motivo cuando aplica.
• PR-183 — Admin único gestor. La edición de parámetros globales es exclusiva del rol admin. No se delega a operator ni price_manager para preservar control centralizado.

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-181 a PR-183 confirmadas por el cliente
• ⬜ Reglas de negocio aplicables aprobadas
• ⬜ Requerimientos funcionales aplicables aprobados
• ⬜ Historia aprobada formalmente por el cliente