Mathieu Benoit
2534d4d022
`env.user.has_group()` répond « oui » dès que l'exécutant est membre du groupe, et la migration l'y ajoute en cours de route. Or la case des réglages lit tout autre chose : ce que `base.group_user` IMPLIQUE (res_config.py, « which groups are implied by the group Employee »). Décider sur l'exécutant créait une liste de prix dans une base dont la fonctionnalité est éteinte, et Odoo prévenait à chaque ouverture des réglages qu'il allait l'archiver. Le contrôle « restant de migration » posait la même mauvaise question ; les deux lisent désormais l'implication du groupe. Vérifié sur copie jetable, dans les deux sens : fonctionnalité éteinte, rien n'est signalé ; activée, constat et réparation reviennent. --- EN --- `env.user.has_group()` says yes as soon as the caller belongs to the group, and the migration adds it along the way. But the settings checkbox reads something else: what `base.group_user` IMPLIES (res_config.py, "which groups are implied by the group Employee"). Deciding on the caller created a pricelist in a database whose feature is off, and Odoo warned on every opening of the settings that it would archive it. The migration-residue check asked the same wrong question; both now read the group implication. Verified on a throwaway copy, both ways: feature off, nothing is reported; feature on, finding and repair come back. Assisted-by: Claude Opus 5 (cherry picked from commit 38ba25e01894f45fb956bcbb08cc3d96a125e648) |
||
|---|---|---|
| .. | ||
| 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_cow_render.py | ||
| fix_duplicate_index.py | ||
| fix_migration_odoo120_to_odoo130.sql | ||
| 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 | ||
| restore_config_defaults.py | ||
| smoke_internal_ui.py | ||
| smoke_public_url.py | ||
| snapshot_cow_views.py | ||
| uninstall_module_list_odoo120_to_odoo130.txt | ||
| uninstall_module_list_odoo140_to_odoo150.txt | ||
| uninstall_module_list_odoo170_to_odoo180.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