Mathieu Benoit
eaf70bdebf
The portal is a third rendering, neither the public site nor the back office: QWeb frontend with counters that each query their own model. The sitemap does not list /my — the page needs a session — and no RPC call goes through it. A migration can break it with nothing else noticing. Measured on a real database: /my answered 500 on a user field a module no longer defines, while every public page and sixteen apps were fine. Two guards the run proved necessary. Requested without a session, /my redirects to the login form and answers 200: counting that as a success would announce a healthy portal never seen. And the production error page shows no traceback, so the reason comes from the server log — attributed by PATH, because the portal is checked first and taking the last trace blamed it for an app's failure. A wrong cause costs more than none. --- FR --- [ADD] migration : ouvrir /my avec l'utilisateur test, et accuser la bonne requête Le portail est un troisième rendu, ni le site public ni le back-office : du QWeb frontend, avec ses compteurs qui interrogent chacun leur modèle. Le sitemap ne liste pas /my — la page demande une session — et aucun appel RPC n'y passe. Une migration peut le casser sans que rien ne le dise. Mesuré sur une vraie base : /my rendait 500 sur un champ utilisateur qu'un module ne définit plus, alors que les pages publiques et seize applications allaient bien. Deux garde-fous que l'essai a rendus nécessaires. Sans session, /my redirige vers le formulaire de connexion et rend 200 : le compter pour une réussite annoncerait un portail jamais vu. Et la page d'erreur de production ne montre aucune trace : la raison vient du journal, attribuée par CHEMIN — le portail est interrogé en premier, et prendre la dernière trace l'accusait de la panne d'une application. 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