The previous implementation of this addon proved being extremely buggy:
- It supplied out of the box a enabled cron to update Odoo that didn't restart the server, which possibly meant that upgrades broke things.
- It overloaded standard Odoo upgrade methods that made i.e. installing an addon sometimes forced to upgrade all other addons in the database.
- The checksum system wasn't smart enough, and some files that didn't need a module upgrade triggered the upgrade.
- It was based on a dirhash library that was untested.
- Some updates were not detected properly.
- Storing a column into `ir.module.module` sometimes forbids uninstalling the addon.
Thanks to Stéphane Bidoul (ACSONE), now we have new methods to perform the same work in a safer and more stable way.
All I'm doing here is:
- Cron is disabled by default.
- Installed checksums are no longer saved at first install.
- Old installations should keep most functionality intact thanks to the migration script.
- Drop some duplicated tests.
- Allow module uninstallation by pre-removing the fields from ir.mode.model.
- When uninstalling the addon, the deprecated features will get removed for next installs always.
Besides that, fixes for the new implementation too:
- When uninstalling the addon, we remove the stored checksum data, so further installations work as if the addon was installed from scratch.
- Files are clearly suffixed with `_deprecated` so we know those features have no support nor migrations.
- Views are removed, since updating from UI was too buggy to support it anymore.
The same problem that was fixed for the `base` addon in #948 happened with random addons that do not depend on `module_auto_update` (a.k.a. any addon) that Odoo decided to load before that one in the graph.
Now we always check for all addons if their state has changed, and make sure to trigger the udpate mechanism that stores the right value in `installed_checksum_dir` field.
If you installed and uninstalled the addon right away, you'd get a ProgrammingError saying that some columns exist no more. Checks are done now using `search_read`, which lets us limit the fields being fetched, and the environment is cleared to make sure nothing fails.
Also we now guess if this own addon has been uninstalled and skip further logic if so, given it would hit broken triggers otherwise as it did before.
* `button_uninstall` calls `get_module_list`, which subsequently forces module upgrades. Add a context validation to prevent that
* Add test for button_immediate_uninstall
* Mock commit for immediate uninstall
* Fix immediate uninstall test
* Switch nesting
* Bump module version
* Recompute dir hashes only when needed - By removing the recomputation from `update_list` we get faster CLI module upgrades and it only performs the autoupdate when using the autoupdate wizard or cron.
* Pass tests if addon is in readonly directory
* Set dependencies to upgrade
[FIX][module_auto_update] Pass tests if addon is in readonly directory
[FIX][module_auto_update] Set dependencies to upgrade
* [IMP] module_auto_update: Create new module
* Add checksum_dir and checksum_installed fields to ir.module.module
* Add checksum_dir to compute current checksum of module directory
in addons path
* Add checksum_installed to store checksum of module directory
when module was last installed or upgraded
* Use checksumdir Python library to compute module directory sha1
hashes, ignoring pyc and pyo extensions
* Extend update_list method to compare modules' checksum_dir and
checksum_installed, then change state of modules with differing
checksums to 'to upgrade'
* Replace Apps/Updates menu item with menu item of same name, which
updates apps list and displays tree view of ir.module.module
records with state 'to upgrade'
* Extend create and write methods to store computed checksum_dir as
checksum_installed during module installation and upgrade, and
set checksum_installed to False on uninstall
* Use context to stop checksum_installed from being updated during
upgrade/uninstall cancellation
* Add cron job to periodically check for module upgrades by
comparing checksums, then perform any available upgrades
* Extend upgrade_module method (called by cron and 'Apply Scheduled
Upgrades' menu item) to call update_list
* Add post_init_hook to store checksum_installed of existing
modules
* Add test coverage
* [FIX] module_auto_update: Fix test broken by changes
* Use dummy module to test update_list method instead of
module_auto_update
Jairo Llopis
Jairo Llopis
Dave Lasley
Brenton Hughes