odoo/odoo#239425
Created by fw-bot
Blocked
- Merge method
- Review
-
CI
- legal/cla: Contributor License Agreement check
- ci/runbot: Odoo Test Suite
- ci/upgrade_enterprise: Test upgrades for enterprise master
- ci/template: Contact runbot team on discord for help.
- ci/style: Optional style check. Ignore it only if strictly necessary.
- ci/security: Required security check. Can only be ignored by security team.
- Linked pull requests
- label
- odoo-dev:19.0-17.0-allow-to-disable-autoinstall-xdo-483407-fw
- head
- e385808e4a9d3f85eb61d0dc61439ada2669b2b6
| odoo/odoo | odoo/documentation | |
|---|---|---|
| 17.0 | #234710 | #15546 |
| 18.0 | #238685 | #15570 |
| saas-18.2 | #239044 missing r+ | #15590 missing r+ |
| saas-18.3 | #239422 missing r+ | #15620 missing r+ |
| saas-18.4 | #239423 missing statuses missing r+ | #15621 missing r+ |
| 19.0 | #239425 missing statuses missing r+ | #15622 missing r+ |
| master | #239427 missing statuses missing r+ | #15623 missing r+ |
[IMP] base: allow to disable autoinstall through command line
In some case, a database can be in a state where some auto install module are not installed
- when the user uninstall a module
- when module was added in stable and a database was created before the addition.
It can lead to issues where an upgrade fails or some business logic does not work as expected because of the missing modules.
This is not easy to reproduce and to test, even if uninstalling such module should in theory work and be tested.
This pr proposes to add a flag "--skip-auto-install" to the config to be able to disable all auto install of modules.
It is open to discussion to change this to a config option, with or without a module list
Initial solution (alternative to avoid a config)
--dev skipautoinstall
Current solutions
(command line param)
--skip-auto-install
Maybe in the future but unlikely
(more flexible)
--skip-auto-install=all
--skip-auto-install=web_enterprise,iap
(krma suggestions)
--skip-auto-install=
--skip-auto-install=web_,iap
Those two last one could be more flexible but the use case are limited and can be done another way with an explicit -i, maybe no worth the additional complexity (mainly since we need to filter in two different places)
Note that this pr uses get on the config just in case the config is monkey patched somewhere to make it more robust.