Migrar módulos de Odoo 17/18 a 19

API

models.Constraint sustituye a _sql_constraints

# Antes (Odoo <= 18)
class ProductTemplate(models.Model):
    _inherit = 'product.template'
    _sql_constraints = [
        ('check_weight', 'CHECK(weight > 0)', 'El peso debe ser mayor que cero'),
    ]

# Odoo 19
class ProductTemplate(models.Model):
    _inherit = 'product.template'

    _check_weight = models.Constraint(
        'CHECK(weight > 0)',
        "El peso debe ser mayor que cero",
    )

El cambio no es solo sintáctico: models.Constraint se declara como atributo de clase con un nombre propio, no como entrada de una lista. Si tu módulo hereda un modelo que ya migró su constraint a la nueva forma, seguir usando _sql_constraints en el heredero puede convivir mal; migra ambos a la vez.

Checklist

Revisión de código antes de tocar la base de datos

• Sustituir todo _sql_constraints por models.Constraint.
• Revisar ir.model.access.csv y record rules tras cualquier renombrado de modelo o campo.
• Buscar llamadas a métodos marcados como deprecados en el changelog oficial de la versión.
• Ejecutar grep sobre el módulo buscando imports directos de odoo.tools que hayan cambiado de ubicación.

Vistas y datos

Xpath, noupdate y referencias rotas

<!-- Comprobar que este xpath sigue siendo válido tras la migración -->
<xpath expr="//field[@name='partner_id']" position="after">
    <field name="custom_field"/>
</xpath>

La estructura del DOM de las vistas base cambia entre versiones mayores con más frecuencia de la que parece. Un xpath que apuntaba a un campo concreto puede dejar de encontrarlo si ese campo se movió de posición o de vista. Instala el módulo en una base de datos de pruebas y revisa el log de instalación completo, no solo si termina en "OK".

Revisa también los datos con noupdate="1": si cambiaste su estructura en el módulo pero la base de datos ya tiene esos registros de una instalación anterior, noupdate impedirá que se actualicen automáticamente al hacer -u.

Validación

Pruebas de regresión antes de tocar producción

• Ejecutar la suite de tests con --test-enable sobre una copia real de la base de datos, no sobre datos demo vacíos.
• Instalar y actualizar (-i y -u) en ese orden, verificando ambos logs.
• Probar manualmente los flujos críticos: los tests automáticos rara vez cubren la interacción completa de UI.