odoo-migrationlisted

# Odoo migrations On `-u` the ORM auto-applies *additive, non-destructive* schema changes. Anything that **moves, renames, or reinterprets existing data** it cannot infer — and its default for a renamed field is to drop the old column and create an empty new one. **That silent data loss is what migration scripts prevent.** Most "needs a migration?" mistakes are writing one that wasn't needed, or skipping one that was. **The rule: if existing rows must change shape or move, you write the migration; if you're only adding, let `-u` do it.** Targets Odoo 17/18, through Odoo 19 (current LTS). Cross-version deprecations: `skills/odoo-introspect/references/version-matrix.md`. ## Does this need a migration? Confirm the real column/field names and types first with `odoo-introspect` (`MODEL=x … < scripts/model_brief.py` → fields + types + stored/compute). For a **rename or drop**, also run the reverse-impact scan — `odoo-ai refs <model> <field>` — so the migration covers *every* dependent (computes, related fields, views, record rules, saved filters, server actions), not just the column you noticed. Then: | Change | Migration? | Why | |---|---|---| | Add a new field | **No** | `-u` creates the column, applies `default` | | Add a new model / index / constraint | **No** | created on `-u` | | Add a **stored computed** field | **No** | `-u` computes it for existing rows | | **Change** an existing stored compute's logic | **Yes (post)** | old rows keep stale values — force recompute |