erplibre/script/odoo/migration
Mathieu Benoit 1ec37defc3 [FIX] check_cow_views: detect on arch shape, not on mode
Two blind spots made the detector miss real breakages.

1. Comparing « mode » is not the right test. What decides the shape an arch
   must have is whether the target declares an inherit_id: with one, the arch
   must be inheritance specs (<data>, <xpath>, position=); without one, it must
   be a standalone template. A view moving from a root template to
   « inherit_id + primary="True" » keeps mode='primary' on BOTH sides, so the
   old test reported nothing while the copy still broke. The comparison is now
   (target declares inherit) vs (stored arch is spec-shaped), and each finding
   carries the reason. A mode change with a matching shape is still reported,
   as a lesser warning.

   arch_db is read as text up to 15.0 and as jsonb from 16.0; both are handled.

2. A module renamed upstream was reported as « module absent », hiding every
   view it owns. renamed_modules is now read from the target OpenUpgrade
   apriori.py (21 entries for 13.0, 56 for 14.0, 39 for 16.0, 20 for 18.0) and
   used before concluding the module is gone.

Also correct the advice printed for a copy at risk: deactivating it is not
enough, an inactive copy keeping the same key still shadows the module view.
Renaming the key is what actually unpairs it.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-08-01 00:54:44 -04:00
..
check_cow_views.py [FIX] check_cow_views: detect on arch shape, not on mode 2026-08-01 00:54:44 -04:00
fix_migration_odoo140_to_odoo150.py [IMP] script: update copyright year to 2026 2026-03-11 23:16:05 -04:00
README.base.md [IMP] migration: per-database uninstall list, with a stated reason 2026-07-31 23:25:43 -04:00
README.fr.md [IMP] migration: per-database uninstall list, with a stated reason 2026-07-31 23:25:43 -04:00
README.md [IMP] migration: per-database uninstall list, with a stated reason 2026-07-31 23:25:43 -04:00
uninstall_module_list_odoo140_to_odoo150.txt [IMP] todo support odoo upgrade 2025-10-31 01:43:26 -04:00

Migration

Run this script when doing database migration. Example :

source ./.venv.odoo15.0_python3.8.20/bin/activate && cat ./script/odoo/migration/fix_migration_odoo140_to_odoo150.py | ./odoo15.0/odoo/odoo-bin shell -d DATABASE

Check uninstall_module_list_odoo140_to_odoo150.txt

Module lists to uninstall

Before a version bump, the migration uninstalls the modules listed in uninstall_module_list_odoo<from>_to_odoo<to>.txt. Two locations are read, the private one first, and the results are merged (duplicates dropped):

  1. private/odoo/migration/<database>/uninstall_module_list_odooXX0_to_odooYY0.txt — specific to ONE database, not versioned. Which modules must be dropped depends on the data, so this is where nearly every entry belongs.
  2. script/odoo/migration/uninstall_module_list_odooXX0_to_odooYY0.txt — shared defaults, versioned, valid for every database.

Syntax: one module per line, with a justification after #. Commas and several names per line are accepted; blank lines and full-line comments are ignored. A module without a stated reason is flagged at runtime: removing a module is a decision someone must be able to review later.

queue_job                        # blocks 12->13, trigger queue_job_notify
mgmtsystem_hazard                # not ported to 13.0
web_syncer                       # dropped upstream