Since this option is soon to be used, this rename is a last tweek to make it more logical to use since it will point to a single upgrade dir most of the time. closes odoo/odoo#44593 X-original-commit: 1c8e2809fb296abce6114b7da906d48a240df418 Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>
Migration have long been only accessible thanks to a symlink from `odoo.base.maintenance` to our private migration repository. Thank to the change of bbb1a8f it is now possible to give a load the migrations scripts from a path given in options. The `initialize_sys_path` function has been updated to hooks the new paths or the legacy symlink and to provide aliases to the previous import logic to ensure backward compatibility. `odoo.upgrades` (`community/odoo/upgrades`) is a new namespace that hook all `--upgrades-paths` directories or the `community/odoo/base/maintenance/migrations` symlink if none is previded. `odoo.addons.base.maintenance.migrations` has been made an alias to `odoo.upgrades`. The `odoo.upgrades` is the desired method for accessing migrations scripts and should be used by all new scripts. closes odoo/odoo#44117 Task: 2178274 X-original-commit: d963cc05acd882729c4eb5ab940dae2a2197e55a Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
This commit adds a new way to use upgrades scripts folders whithout needing to symlink them to an hardcoded path. The folders specified in --upgrades-paths is then being used by migration.py to find and execute migrations scripts per module specified in the -u CLI option. The folder needs to have the following structure: - <upgrades_paths folder 1> - <module1 name> - <version1> - <script1> - <script2> - ... - <scriptn> - <version2> - <scripts> - <module2 name> - <versions> - <scripts> - ... - <upgrades_paths folder 2> - ... Update odoo/tools/config.py Co-Authored-By: Olivier Dony <odony@users.noreply.github.com>
A special folder named `0.0.0` can contain scripts that are run on upgrade of any version. They are useful to make some sanity checks or other verifications to ensure database consistency. The first version of this patch used the more eye-catching `any` for the migration folder, but it was problematic for upgrading from an older version that doesn't contain this patch. Using a version "number" containing two dots is required to avoid it being prefixed with the server version (see `convert_version` method) and resulting in a version like `10.0.any`. Such version would have been executed, even without this patch, when upgrading from an older major server version (9.0.1.0 < 10.0.any). closes odoo/odoo#34268 Signed-off-by: Christophe Simonis <chs@odoo.com>
Odoo no longer supports python 2, thus some of these helpers can and
have been replaced by python 3 built-ins, therefore there is no need for
them to stay defined.
The removed helpers are:
* izip, imap and ifilter
* unichr, text_type
* implements_to_string, implements_iterator
* string_types, integer_types
* to_native
The python 2 shims have also been removed, and only the python 3 helpers
have been kept, because they can still be usable (i.e. accepting
both bytes and str for functions that can only accept one of the two)
[REM] pyjsparser: remove PY3 shims
They're no longer necessary as Odoo doesn't officially support python 2
anymore.
closes odoo/odoo#28519
This commit replaces calls to pycompat helpers that were intended for
python 2 <-> python 3 interoperability for python 3 builtins, as python
2 is no longer officially supported by Odoo.
This includes:
* calls to imap/izip/ifilter replaced by map/zip/filter
* uses of text_type replaced by str
* uses of unichr replaced by chr
* calls to implements_to_string, implements_iterator removed
* string_types and integer_types replaced by str, int respectively
* calls to to_native replaced by calls to to_text
This is done in preparation to the removal of these deprecated helpers
in the following commit.
closes odoo/odoo#28255
Migration files must contain `-` in its name for being executed