Mathieu Benoit
fc23bd6f96
The back-office pass was already there, and it works. What did not work was the way it declined: one discreet line at the end of a long report, saying « the database was not neutralized ». On six databases of a real migration the test user is present up to the 15 bump and GONE at 17 and 18 — so the pass stopped silently exactly where a migration does the most damage, and said something that was not even true. The migration knows what it neutralized, so it now asks for the back office by name. A missing test user on a database it neutralized is a finding, printed loudly and counted as a failure. A missing tool is too: returning None made the whole pass vanish without a word. And it says UP FRONT which passes will run, on that database, by name. --- FR --- [FIX] migration : un back-office sauté ne doit pas se lire comme un sain La passe back-office était déjà là et elle fonctionne. Ce qui ne fonctionnait pas, c'est sa façon de renoncer : une ligne discrète en fin d'un long rapport, disant « la base n'a pas été neutralisée ». Sur les six bases d'une vraie migration, l'utilisateur test est présent jusqu'au palier 15 et ABSENT en 17 et 18 — la passe s'arrêtait donc sans bruit là où une migration fait le plus de dégâts, en disant quelque chose de faux. La migration sait ce qu'elle a neutralisé : elle réclame désormais le back-office. Un utilisateur test manquant sur une base qu'elle a neutralisée est une trouvaille, affichée fort et comptée comme un échec. Un outil absent aussi : rendre None faisait disparaître la passe entière. Et elle annonce AVANT de lancer ce qui sera parcouru. Assisted-by: Claude Opus 5 |
||
|---|---|---|
| .. | ||
| check_cow_views.py | ||
| check_stale_scss.py | ||
| check_stale_scss_tui.py | ||
| cow_drift.py | ||
| cow_drift_tui.py | ||
| database_cleanup.py | ||
| fix_migration_odoo130_to_odoo140.sql | ||
| fix_migration_odoo140_to_odoo150.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