Mathieu Benoit
7e30377e56
OpenUpgrade converts the COLUMN and never the ARCH:
def _fix_list_view_type(cr):
cr.execute("UPDATE ir_ui_view SET type='list' WHERE type='tree'")
so the load dies on "the root node of a list view should be <list>".
A module view recovers at its next update, which rewrites the arch from
XML. A view with no xmlid -- a hand-made list, a website copy -- is
rewritten by nothing and stays broken forever. The report says which is
which, because the two call for different work.
Every occurrence, not just the root: a <tree> nested in a form is a
one2many list and is refused just the same. Odoo 18's own addons hold
none, so nothing legitimate is at risk. Gated on version 18: before it,
the tag is correct and "fixing" it would break healthy views.
Four tests run the SQL against a real PostgreSQL. A text assertion
cannot see what a query does -- it took a live run to prove every
language of the jsonb arch is converted, not just en_US.
--- FR ---
OpenUpgrade convertit la COLONNE et jamais l'ARCH, d'où l'échec sur « le
nœud racine d'une vue list devrait être <list> ». Une vue de module s'en
remet à sa prochaine mise à jour ; une vue sans xmlid — liste faite
main, copie de site — n'est réécrite par rien. Le rapport distingue les
deux, car le travail diffère.
Toutes les occurrences, pas seulement la racine : un <tree> imbriqué
dans un formulaire est une liste one2many, refusée pareillement. Les
addons d'Odoo 18 n'en portent aucun. Bridé à la 18 : avant, la balise
est juste.
Quatre tests exécutent le SQL contre un vrai PostgreSQL. Une assertion
sur du texte ne voit pas ce qu'une requête fait — il a fallu l'exécuter
pour prouver que toutes les langues du jsonb sont converties.
Assisted-by: Claude Opus 5
|
||
|---|---|---|
| .. | ||
| check_cow_views.py | ||
| check_hidden_models.py | ||
| check_stale_scss.py | ||
| check_stale_scss_tui.py | ||
| cow_drift.py | ||
| cow_drift_tui.py | ||
| database_cleanup.py | ||
| dms_access_repair.py | ||
| fix_migration_odoo130_to_odoo140.sql | ||
| fix_migration_odoo140_to_odoo150.py | ||
| fix_migration_odoo170_to_odoo180.sql | ||
| fix_view_type.py | ||
| neutralize_cow_views.py | ||
| README.base.md | ||
| README.fr.md | ||
| README.md | ||
| reset_stale_cow_tui.py | ||
| reset_stale_cow_views.py | ||
| smoke_internal_ui.py | ||
| smoke_public_url.py | ||
| snapshot_cow_views.py | ||
| 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