fix: [TESIS-158] let a webhook order be saved without city nor province

[LauAubert]

Ticket de Jira

https://proyectofinalfrlp.atlassian.net/browse/TESIS-158

ID provisorio: se reemplaza por la clave real al cargar la card en Jira. Card: cards/027.md. Sale de una auditoría de código del front (TESIS-89).

---

Descripción

El formulario de modificación de una orden (S09) exige ciudad y provincia (destinationSchema), pero las órdenes que entran por webhook nunca las traen: Orders::TranslateWebhookPayload no tiene esas claves y la API las acepta vacías (TESIS-128). El formulario abría inválido, el modo onChange de React Hook Form no marca nada hasta que se toca cada campo, y «Guardar cambios» quedaba apagado sin ningún campo en rojo, aunque el operador sólo quisiera pasar la orden a «Pagada».

Mandar los campos vacíos tampoco habría servido: la API valida customer_province contra la lista de provincias con allow_nil, así que una provincia vacía es un 422.

Decisiones que conviene mirar:

El domicilio cuenta sólo si se tocó. canSave exige el domicilio válido únicamente cuando está dirty, y toUpdatePayload no manda sus cuatro campos si no cambiaron (UpdateOrder sólo actualiza lo que recibe). Así, cambiar el estado o las líneas de una orden de webhook funciona, y el domicilio queda como vino del canal.

Si se toca, se valida entero. Al empezar a editar el domicilio se dispara la validación de todos sus campos: una ciudad o una provincia que ya faltaban se marcan en rojo, en lugar de apagar el guardado sin explicación.

• OrderEditForm: canSave con el domicilio condicionado a destinationDirty, trigger del domicilio cuando se ensucia, y toUpdatePayload(..., destinationDirty).
• toUpdatePayload acepta includeDestination (por defecto true, como antes).
• UpdateOrderPayload declara opcionales los cuatro campos del domicilio.
• Tests: una orden sin ciudad ni provincia se puede marcar como pagada, el PUT no manda el domicilio, tocar el domicilio muestra lo que falta; y el payload sin domicilio.

---

Evidencia visual

Pendiente de captura.

---

Cómo probar

1. Abrir «Modificar orden» de una orden que entró por webhook (sin ciudad ni provincia).
2. Cambiar Estado a «Pagada» → «Guardar cambios» se habilita; guardar → 200 y vuelve al detalle. En master el botón queda apagado.
3. Escribir algo en «Calle y número» → aparecen «Ingresá la ciudad.» y el de provincia, y el botón se apaga hasta completarlos.

Verificación: npm run test (680 tests, 0 fallas), npm run lint, npm run format:check y npm run build limpios.

---

Impacto y consideraciones

¿Introduce breaking changes?
No. Una orden con domicilio completo se guarda igual que antes.

¿Requiere nuevas variables de entorno?
No

¿Afecta la arquitectura o genera un nuevo patrón?
No

🤖 Generated with Claude Code

[TomasMartin2004]

Revisado. Lo veo bien para implementar.

Esto ya te está pegando. Las órdenes que entran por webhook no traen ciudad ni provincia —Orders::TranslateWebhookPayload no tiene esas claves y la API las acepta vacías—, pero el formulario de modificación las exige. Con el modo onChange de React Hook Form, que no marca nada hasta que se toca cada campo, el resultado es «Guardar cambios» apagado y ningún campo en rojo: el operador no tiene forma de saber qué falta. La orden #11 que entró de Shopify el otro día cae exactamente en este caso, así que es un defecto alcanzable hoy en el entorno desplegado.

Lo que verifiqué

• El domicilio ahora viaja sólo si el operador lo tocó (includeDestination en toUpdatePayload). Fui a chequear el lado de Rails: ORDER_FIELDS permite esas claves pero no las exige, así que una clave ausente deja el valor como estaba. El cambio es seguro y no borra el domicilio de las órdenes que sí lo tienen.
• El default = true del parámetro nuevo mantiene a los llamadores existentes sin tocar. Bien.
• El useEffect que dispara trigger() cuando el domicilio se ensucia resuelve la otra mitad del problema: en cuanto se toca un campo, se validan todos y el operador ve qué falta, en vez de descubrirlo campo por campo. Hay un test dedicado (asks for every missing field once the address is touched).
• Los tres casos están cubiertos: se puede marcar como pagada, no se manda el domicilio que no se tocó, y tocarlo pide todo lo que falta.
• Los campos del payload pasan a opcionales en types.ts con el porqué en el docstring, no sueltos.

[TomasMartin2004]

Revisión del diff completo. El código es idéntico al que leí cuando los PRs estaban en draft —ningún commit nuevo—, así que lo que sigue es el veredicto formal.

✅ Aprobado

Esto ya está pegando en producción local. Las órdenes que entran por webhook no traen ciudad ni provincia —Orders::TranslateWebhookPayload no tiene esas claves y la API las acepta vacías— pero el formulario de modificación las exige. Con el modo onChange de React Hook Form, que no marca nada hasta que se toca cada campo, el resultado es «Guardar cambios» apagado y ningún campo en rojo: el operador no tiene forma de saber qué falta.

La orden de Shopify que entró con TESIS-138 cae exactamente en este caso, así que es un defecto alcanzable hoy en el entorno desplegado.

Lo que verifiqué

• El domicilio viaja sólo si el operador lo tocó. Fui a chequear el lado de Rails: ORDER_FIELDS permite esas claves pero no las exige, así que una clave ausente deja el valor como estaba. El cambio es seguro y no borra el domicilio de las órdenes que sí lo tienen.
• El default = true del parámetro nuevo mantiene a los llamadores existentes sin tocar.
• El useEffect que dispara trigger() cuando el domicilio se ensucia resuelve la otra mitad: en cuanto se toca un campo se validan todos, en vez de descubrirlo campo por campo. Hay test dedicado.
• Los tres casos están cubiertos: se puede marcar como pagada, no se manda el domicilio que no se tocó, y tocarlo pide todo lo que falta.