Mathieu Benoit
045ccc1c85
A copy-on-write view freezes the structure of the module view it was copied from. When that module view changes mode between two versions, the copy keeps an arch written for the old mode and the upgrade dies on « Element ... cannot be located in parent view », hours into the migration. Measured on a real 12.0 database: portal.frontend_layout is declared primary in 12.0 (full QWeb template, so a full-template arch is legitimate) and becomes an extension in 13.0 (inherit_id + xpath). The 2021 COW copy follows the module, turns into an extension, and keeps its 12.0 arch. The customization is genuine; the breakage is produced by the migration. check_cow_views.py compares the mode stored in database with the mode declared in the target version sources and sorts the views in three buckets: at risk (mode change), module absent from the target version, and pages made from the editor (not at risk). Read-only, and called from step 2 so the list is known before the long version loop rather than during it. On the reference database it reports exactly the view that broke the upgrade, plus 7 views whose module is gone in 13.0 (custom theme included). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| check_cow_views.py | ||
| fix_migration_odoo140_to_odoo150.py | ||
| README.base.md | ||
| README.fr.md | ||
| README.md | ||
| uninstall_module_list_odoo140_to_odoo150.txt | ||
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):
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.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