[gal-adhoc]

Tarea: https://www.adhoc.inc/odoo/project.task/76727

Migración de academic_payment_portal de 19.0 a 20.0.

Qué cambió

• Manifiesto: la versión pasa a 20.0.1.0.0 y installable a True. depends (account_payment), auto_install y la licencia (AGPL-3) no cambian.

• Código: sin cambios. El Python y el XML son los de 19.0. Nada de lo que usa el módulo cambió en 20:

  • _has_to_be_paid y _create_payment de account_payment siguen con la misma firma.
  • Los campos de account.move que lee existen con el mismo tipo.
  • El ancla account_batch_payment de los ajustes sigue en account.res_config_settings_view_form.

• Traducciones: se exportaron .pot y es.po para 20 y se tradujo el nombre del módulo. "Display Name" toma la redacción del core.

• Tests nuevos (tests/test_portal_payment.py). Prueban el código de 20, no son red de regresión de 19, porque el módulo no tenía tests:

  • con la opción de la compañía activa, en el portal solo se puede pagar la factura con el vencimiento más viejo; con la opción apagada, todas; pagada la más vieja, pasa a ser pagable la siguiente;
  • un pago desde el portal hecho por otro contacto queda a nombre del cliente de la factura y la concilia.

  Se vieron fallar rompiendo el módulo a propósito: T1 sin la condición de _has_to_be_paid, T2 sin forzar el partner en _create_payment.

Notas de cierre

• Extensión de account_payment_multi: el controller la extiende dentro de un try/except ImportError, y account_payment_multi no es instalable en 19.0 ni en 20.0. Probado en una base 20:

  • sin su código en el addons_path, el import falla y no se define nada;
  • con su código en el path y sin instalar, la subclase se define pero no entra al ruteo (get_leaf_classes solo recorre módulos instalados), así que no tiene efecto ni rompe nada.

  Vuelve a tener efecto cuando ese módulo se migre.

• Data: no hace falta script. El único campo guardado, res.company.users_can_pay_only_oldest_invoice (Boolean, default True), es igual que en 19.0.

• Comportamientos que ya estaban en 19 y no se tocan en esta migración, a evaluar aparte:

  • la cola de facturas no filtra por compañía ni por commercial partner;
  • con dos facturas del mismo vencimiento no hay desempate;
  • si la factura más vieja está bloqueada, no se puede pagar ninguna.

• Verificación:

  • en base 20 local, el módulo instala sin warnings y los tests del módulo pasan (2/2);
  • pre-commit limpio;
  • chequeos estáticos, imports y vistas heredadas sin hallazgos;
  • no se probó sobre una base que haya pasado el upgrade real, porque runbot todavía no corre el salto a 20.

[roboadhoc]

[lef-adhoc]

@roboadhoc r+ nobump rebase-ff

[roboadhoc]

Merge method set to rebase and fast-forward.