When OpenUpgrade failed, todo_upgrade_execute offered the generic « [1] to redo the command ». Replaying it re-ran OpenUpgrade on the database it had just half migrated, which never recovers. That call now passes wait_at_error=False, and the failure message explains that the clone step has been reset so a relaunch DROPS and REBUILDS the intermediate database from the previous version. The resume menu gains « [4.N] »: replay the step 4 loop from one version bump. Only the per-version lists are trimmed from that index, so earlier bumps stay migrated and steps 0 to 3 are untouched. Resetting the clone entry is the whole point: the intermediate database of a failed bump must be rebuilt, not upgraded again. « [4] » still replays every bump. The per-bump uninstall files were also read at step 1 only, for the source version, so uninstall_module_list_odoo130_to_odoo140.txt existed in name but was never read. The step 4 loop now reads the file of the bump it is about to perform, merged with the answers already stored in the progression. Verified against the real progression (13 and 14 migrated): the menu offers 13/14/15/16/17/18, and replaying from 14 turns every per-version list from [True, True, False...] into [True, False, ...] while state_4_reach_open_upgrade and steps 0-3 survive. A 13->14 list of 4 modules is read with its reasons. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| database_manager.py | ||
| kdbx_manager.py | ||
| logo_ascii.txt | ||
| qemu_install_monitor.py | ||
| README.base.md | ||
| README.fr.md | ||
| README.md | ||
| source_todo.sh | ||
| todo.json | ||
| todo.py | ||
| todo_example.json | ||
| todo_file_browser.py | ||
| todo_i18n.py | ||
| todo_telemetry.py | ||
| todo_upgrade.py | ||
| version_manager.py | ||
TODO is an assistant robot to use ERPLibre
Execute it with ./script/todo/todo.py or make todo.
For a new project, copy todo_example.json to private/todo/todo_override.json | private/todo/todo_override_private.json and edit it.