[ADD] Upgrade documentation: Upgrade scripts and Util package
closes odoo/documentation#7548
X-original-commit: 16a209c750
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
This commit is contained in:
parent
e8576b7a04
commit
c330f4d72e
@ -33,7 +33,6 @@ These are the steps to follow to upgrade customized databases:
|
||||
#. :ref:`Test extensively and do a rehearsal <upgrade_custom/testing_rehearsal>`.
|
||||
#. :ref:`Upgrade the production database <upgrade_custom/production>`.
|
||||
|
||||
|
||||
.. _upgrade_custom/stop_developments:
|
||||
|
||||
Step 1: Stop the developments
|
||||
@ -47,14 +46,13 @@ Needless to say, bug fixing is exempt from this recommendation.
|
||||
Once you have stopped development, it is a good practice to assess the developments made and compare
|
||||
them with the features introduced between your current version and the version you are targeting.
|
||||
Challenge the developments as much as possible and find functional workarounds. Removing redundancy
|
||||
between your developments and the standard version of Odoo will lead to an eased
|
||||
upgrade process and reduce technical debt.
|
||||
between your developments and the standard version of Odoo will lead to an eased upgrade process
|
||||
and reduce technical debt.
|
||||
|
||||
.. note::
|
||||
You can find information on the changes between versions in the `Release Notes
|
||||
<https:/odoo.com/page/release-notes>`_.
|
||||
|
||||
|
||||
.. _upgrade_custom/request_upgrade:
|
||||
|
||||
Step 2: Request an upgraded database
|
||||
@ -71,7 +69,6 @@ properly. If that's not the case, and the upgrade request fails, request the ass
|
||||
the `support page <https://odoo.com/help?stage=migration>`_ by selecting the option related to
|
||||
testing the upgrade.
|
||||
|
||||
|
||||
.. _upgrade_custom/empty_database:
|
||||
|
||||
Step 3: Empty database
|
||||
@ -85,7 +82,7 @@ features, and guarantees that they will not cause any issues when upgrading the
|
||||
Making the custom modules work in an empty database also helps avoid changes and wrong
|
||||
configurations that might be present in the production database (like studio customization,
|
||||
customized website pages, email templates or translations). They are not intrinsically related to
|
||||
the custom modules and that can raise unwanted issues in this stage of the upgraded process.
|
||||
the custom modules and that can raise unwanted issues in this stage of the upgrade process.
|
||||
|
||||
To make custom modules work on an empty database we advise to follow these steps:
|
||||
|
||||
@ -190,24 +187,84 @@ To make sure the custom code is working flawlessly in the new version, follow th
|
||||
Migrate the data
|
||||
----------------
|
||||
|
||||
During the upgrade of the custom modules, you might have to use migration scripts to reflect changes
|
||||
from the source code to their corresponding data.
|
||||
During the upgrade of the custom modules, you might have to use
|
||||
:doc:`upgrade scripts <../reference/upgrade_scripts>` to reflect changes from the source code
|
||||
to their corresponding data. Together with the upgrade scripts, you can also make use of the
|
||||
:doc:`../reference/upgrade_utils` and its helper functions.
|
||||
|
||||
- Any technical data that was renamed during the upgrade of the custom code (models, fields,
|
||||
external identifiers) should be renamed using migration scripts to avoid data loss during the
|
||||
module upgrade.
|
||||
external identifiers) should be renamed using upgrade scripts to avoid data loss during the
|
||||
module upgrade. See also: :meth:`rename_field`, :meth:`rename_model`, :meth:`rename_xmlid`.
|
||||
- Data from standard models removed from the source code of the newer Odoo version and from the
|
||||
database during the standard upgrade process might need to be recovered from the old model table
|
||||
if it is still present.
|
||||
|
||||
Migration scripts can also be used to:
|
||||
.. example::
|
||||
Custom fields for model ``sale.subscription`` are not automatically migrated from Odoo 15 to
|
||||
Odoo 16 (when the model was merged into ``sale.order``). In this case, a SQL query can be
|
||||
executed on an upgrade script to move the data from one table to the other. Take into account
|
||||
that all columns/fields must already exist, so consider doing this in a ``post-`` script (See
|
||||
:ref:`upgrade-scripts/phases`).
|
||||
|
||||
.. spoiler::
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
def migrate(cr, version):
|
||||
cr.execute(
|
||||
"""
|
||||
UPDATE sale_order so
|
||||
SET custom_field = ss.custom_field
|
||||
FROM sale_subscription ss
|
||||
WHERE ss.new_sale_order_id = so.id
|
||||
"""
|
||||
)
|
||||
|
||||
Check the documentation for more information on :doc:`../reference/upgrade_scripts`.
|
||||
|
||||
Upgrade scripts can also be used to:
|
||||
|
||||
- Ease the processing time of an upgrade. For example, to store the value of computed stored fields
|
||||
on models with an excessive number of records by using SQL queries.
|
||||
- Recompute fields in case the computation of their value has changed.
|
||||
- Uninstall unwanted custom modules.
|
||||
- Recompute fields in case the computation of their value has changed. See also
|
||||
:meth:`recompute_fields`.
|
||||
- Uninstall unwanted custom modules. See also :meth:`remove_module`.
|
||||
- Correct faulty data or wrong configurations.
|
||||
|
||||
Running and testing upgrade scripts
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. tabs::
|
||||
|
||||
.. group-tab:: Odoo Online
|
||||
|
||||
As the instalation of custom modules containing Python files is not allowed on Odoo Online
|
||||
databases, it is not possible to run upgrade scripts on this platform.
|
||||
|
||||
.. group-tab:: Odoo.sh
|
||||
|
||||
As explained on the `Odoo.sh` tab of :ref:`upgrade/request-test-database`, Odoo.sh is
|
||||
integrated with the upgrade platform.
|
||||
|
||||
Once the upgrade of a staging branch is on "Update on commit" mode, each time a commit is
|
||||
pushed on the branch, the upgraded backup is restored and all the custom modules are updated.
|
||||
This update includes the execution of the upgrade scripts.
|
||||
|
||||
When upgrading the production database, the execution of the upgrade scripts is also part of
|
||||
the update of the custom modules done by the platform when the upgraded database is restored.
|
||||
|
||||
.. group-tab:: On-premise
|
||||
|
||||
Once you receive the upgraded dump of the database from the `Upgrade platform
|
||||
<https://upgrade.odoo.com>`_, deploy the database and update all the custom modules by
|
||||
invoking the command :doc:`odoo-bin </developer/reference/cli>` in the shell.
|
||||
To update the custom modules, use the option: `-u <modules>,
|
||||
--update <modules>`.
|
||||
|
||||
.. important::
|
||||
As mentioned in the :doc:`CLI documentation </developer/reference/cli>`, the command used
|
||||
to call the CLI depends on how you installed Odoo.
|
||||
|
||||
.. _upgrade_custom/upgraded_database/test_custom:
|
||||
|
||||
Test the custom modules
|
||||
@ -221,13 +278,12 @@ Things to pay attention to:
|
||||
|
||||
- Views not working: During the upgrade, if a view causes issues because of its content, it gets
|
||||
disabled. You can find the information on disabled views on the :ref:`Upgrade report
|
||||
<upgrade/upgrade_report>`. This view needs to be activated again. To achieve this, we recommend
|
||||
the use of migration scripts.
|
||||
<upgrade/upgrade_report>`. This view needs to be activated again (or removed if not useful anymore).
|
||||
To achieve this, we recommend the use of upgrade scripts.
|
||||
- :doc:`Module data <../tutorials/define_module_data>` not updated: Custom records that have the
|
||||
``noupdate`` flag are not updated when upgrading the module in the new database. For the custom
|
||||
data that needs to be updated due to changes in the new version, we recommend to use migration
|
||||
scripts to do so.
|
||||
|
||||
data that needs to be updated due to changes in the new version, we recommend to use upgrade
|
||||
scripts to do so. See also: :meth:`update_record_from_xml`.
|
||||
|
||||
.. _upgrade_custom/testing_rehearsal:
|
||||
|
||||
@ -247,7 +303,6 @@ In addition to that, make a full rehearsal of the upgrade process the day before
|
||||
production database to avoid undesired behavior during the upgrade and to detect any issue that
|
||||
might have occurred with the migrated data.
|
||||
|
||||
|
||||
.. _upgrade_custom/production:
|
||||
|
||||
Step 6: Production upgrade
|
||||
|
@ -12,5 +12,7 @@ Reference
|
||||
reference/user_interface
|
||||
reference/standard_modules
|
||||
reference/cli
|
||||
reference/upgrade_scripts
|
||||
reference/upgrade_utils
|
||||
reference/external_api
|
||||
reference/extract_api
|
||||
|
101
content/developer/reference/upgrade_scripts.rst
Normal file
101
content/developer/reference/upgrade_scripts.rst
Normal file
@ -0,0 +1,101 @@
|
||||
===============
|
||||
Upgrade scripts
|
||||
===============
|
||||
|
||||
An upgrade script is a Python file containing a function called :meth:`migrate`, which the upgrade
|
||||
process invokes during the update of a module.
|
||||
|
||||
.. method:: migrate(cr, version)
|
||||
|
||||
:param cr: current database cursor
|
||||
:type cr: :class:`~odoo.sql_db.Cursor`
|
||||
:param str version: installed version of the module
|
||||
|
||||
Typically, this function executes one or multiple SQL queries and can also access Odoo's ORM, as
|
||||
well as the :doc:`./upgrade_utils`.
|
||||
|
||||
Writing upgrade scripts
|
||||
=======================
|
||||
|
||||
Upgrade scripts follow a specific tree structure with a naming convention which determines when they
|
||||
are executed.
|
||||
|
||||
The structure of an upgrade script path is :file:`$module/migrations/$version/{pre,post,end}-*.py`,
|
||||
where `$module` is the module for which the script will run, `$version` is the full version of the
|
||||
module (including Odoo's major version and the module's minor version) and `{pre|post|end}-*.py` is
|
||||
the file that needs to be executed. The file's name will determine the :ref:`phase
|
||||
<upgrade-scripts/phases>` and order in which it is executed for that module and version.
|
||||
|
||||
.. note::
|
||||
Upgrade scripts are only executed when the module is being updated. Therefore, the
|
||||
module's minor version set in the `$version` directory needs to be higher than the module's
|
||||
installed version and equal or lower to the updated version of the module.
|
||||
|
||||
.. example::
|
||||
|
||||
Directory structure of an upgrade script for a custom module named `awesome_partner` upgraded
|
||||
to version `2.0` on Odoo 17.
|
||||
|
||||
.. code-block:: text
|
||||
|
||||
awesome_partner/
|
||||
|-- migrations/
|
||||
| |-- 17.0.2.0/
|
||||
| | |-- pre-exclamation.py
|
||||
|
||||
Two upgrade scripts examples with the content of the :file:`pre-exclamation.py`, file adding
|
||||
"!" at the end of partners' names:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
import logging
|
||||
|
||||
_logger = logging.getLogger(__name__)
|
||||
|
||||
|
||||
def migrate(cr, version):
|
||||
cr.execute("UPDATE res_partner SET name = name || '!'")
|
||||
_logger.info("Updated %s partners", cr.rowcount)
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
import logging
|
||||
from odoo.upgrade import util
|
||||
|
||||
_logger = logging.getLogger(__name__)
|
||||
|
||||
|
||||
def migrate(cr, version):
|
||||
env = util.env(cr)
|
||||
|
||||
partners = env["res.partner"].search([])
|
||||
for partner in partners:
|
||||
partner.name += "!"
|
||||
|
||||
_logger.info("Updated %s partners", len(partners))
|
||||
|
||||
Note that in the second example, the script takes advantage of the :doc:`./upgrade_utils` to
|
||||
access the ORM. Check the documentation to find out more about this library.
|
||||
|
||||
.. _upgrade-scripts/phases:
|
||||
|
||||
Phases of upgrade scripts
|
||||
=========================
|
||||
|
||||
The upgrade process consists of three phases for each version of each module:
|
||||
|
||||
#. The pre-phase, before the module is loaded.
|
||||
#. The post-phase, after the module and its dependencies are loaded and updated.
|
||||
#. The end-phase, after all modules have been loaded and updated for that version.
|
||||
|
||||
Upgrade scripts are grouped according to the first part of their filenames into the corresponding
|
||||
phase. Within each phase, the files are executed according to their lexical order.
|
||||
|
||||
.. admonition:: Execution order of example scripts for one module in one version
|
||||
|
||||
#. :file:`pre-10-do_something.py`
|
||||
#. :file:`pre-20-something_else.py`
|
||||
#. :file:`post-do_something.py`
|
||||
#. :file:`post-something.py`
|
||||
#. :file:`end-01-migrate.py`
|
||||
#. :file:`end-migrate.py`
|
279
content/developer/reference/upgrade_utils.rst
Normal file
279
content/developer/reference/upgrade_utils.rst
Normal file
@ -0,0 +1,279 @@
|
||||
=============
|
||||
Upgrade utils
|
||||
=============
|
||||
|
||||
`Upgrade utils <https://github.com/odoo/upgrade-util/>`_ is a library that contains helper functions
|
||||
to facilitate the writing of upgrade scripts. This library, used by Odoo for the upgrade scripts of
|
||||
standard modules, provides reliability and helps speed up the upgrade process:
|
||||
|
||||
- The helper functions help make sure the data is consistent in the database.
|
||||
- It takes care of indirect references of the updated records.
|
||||
- Allows calling functions and avoid writing code, saving time and reducing development risks.
|
||||
- Helpers allow to focus on what is important for the upgrade and not think of details.
|
||||
|
||||
Installation
|
||||
============
|
||||
|
||||
Clone the `Upgrade utils repository <https://github.com/odoo/upgrade-util/>`_ locally and start
|
||||
``odoo`` with the ``src`` directory prepended to the ``--upgrade-path`` option.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ ./odoo-bin --upgrade-path=/path/to/upgrade-util/src,/path/to/other/upgrade/script/directory [...]
|
||||
|
||||
On platforms where you do not manage Odoo yourself, you can install this library via `pip`:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ python3 -m pip install git+https://github.com/odoo/upgrade-util@master
|
||||
|
||||
On `Odoo.sh <https://www.odoo.sh/>`_ it is recommended to add it to the :file:`requirements.txt` of
|
||||
the custom repository. For this, add the following line inside the file::
|
||||
|
||||
odoo_upgrade @ git+https://github.com/odoo/upgrade-util@master
|
||||
|
||||
Using Upgrade utils
|
||||
===================
|
||||
|
||||
Once installed, the following packages are available for the upgrade scripts:
|
||||
|
||||
- :mod:`odoo.upgrade.util`: the helper itself.
|
||||
- :mod:`odoo.upgrade.testing`: base TestCase classes.
|
||||
|
||||
To use it in upgrade scripts, simply import it:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
from odoo.upgrade import util
|
||||
|
||||
|
||||
def migrate(cr, version):
|
||||
# Rest of the script
|
||||
|
||||
Now, the helper functions are available to be called through ``util``.
|
||||
|
||||
Util functions
|
||||
==============
|
||||
|
||||
Upgrade utils provides many useful functions to ease the upgrade process. Here, we describe some
|
||||
of the most useful ones. Refer to the `util folder
|
||||
<https://github.com/odoo/upgrade-util/tree/master/src/util>`_ for the comprehensive declaration of
|
||||
helper functions.
|
||||
|
||||
.. note::
|
||||
|
||||
All util functions receive :attr:`cr` as a parameter. This refers to the database cursor. Pass
|
||||
the one received as a parameter in :meth:`migrate`.
|
||||
|
||||
Fields
|
||||
------
|
||||
|
||||
.. `[source] <https://github.com/odoo/upgrade-util/blob/master/src/util/fields.py#L91>`_
|
||||
.. method:: remove_field(cr, model, fieldname, cascade=False, drop_column=True, skip_inherit=())
|
||||
|
||||
Remove a field and its references from the database.
|
||||
|
||||
:param str model: model name of the field to remove
|
||||
:param str fieldname: name of the field to remove
|
||||
:param bool cascade: whether the field's column and inheritance are removed in ``CASCADE``
|
||||
:param bool drop_column: whether the field's column is dropped
|
||||
:param list(str) or str skip_inherit: list of models whose field's inheritance is skipped.
|
||||
Use ``"*"`` to skip all inheritances
|
||||
|
||||
.. `[source] <https://github.com/odoo/upgrade-util/blob/master/src/util/fields.py#L362>`_
|
||||
.. method:: rename_field(cr, model, old, new, update_references=True, domain_adapter=None, skip_inherit=())
|
||||
|
||||
Rename a field and its references from ``old`` to ``new``.
|
||||
|
||||
:param str model: model name of the field to rename
|
||||
:param str old: current name od the field to rename
|
||||
:param str new: new name od the field to rename
|
||||
:param bool update_references: whether all references of field ``old`` to ``new`` are replaced
|
||||
in: ``ir_filters``, ``ir_exports_line``, ``ir_act_server``, ``mail_alias``,
|
||||
``ir_ui_view_custom (dashboard)``, ``domains (using "domain_adapter")``, ``related fields``
|
||||
:param function domain_adapter: function that takes three arguments and returns a domain that
|
||||
substitutes the original leaf: ``(leaf: Tuple[str,str,Any], in_or: bool, negated: bool)`` ->
|
||||
``List[Union[str,Tuple[str,str,Any]]]``
|
||||
:param list(str) or str skip_inherit: list of models whose field's inheritance is skipped.
|
||||
Use ``"*"`` to skip all inheritances
|
||||
|
||||
.. `[source] <https://github.com/odoo/upgrade-util/blob/master/src/util/fields.py#L337>`_
|
||||
.. method:: move_field_to_module(cr, model, fieldname, old_module, new_module, skip_inherit=())
|
||||
|
||||
Move a field's reference in ``ir_model_data`` table from ``old_module`` to ``new_module``.
|
||||
|
||||
:param str model: model name of the field to move
|
||||
:param str fieldname: name of the field to move
|
||||
:param str old_module: current module name of the field to move
|
||||
:param str new_module: new module name of the field to move
|
||||
:param list(str) or str skip_inherit: list of models whose field's inheritance is skipped.
|
||||
Use ``"*"`` to skip all inheritances
|
||||
|
||||
Models
|
||||
------
|
||||
|
||||
.. `[source] <https://github.com/odoo/upgrade-util/blob/master/src/util/models.py#L53>`_
|
||||
.. method:: remove_model(cr, model, drop_table=True, ignore_m2m=())
|
||||
|
||||
Remove a model and its references from the database.
|
||||
|
||||
:param str model: name of the model to remove
|
||||
:param bool drop_table: whether the model's table is dropped
|
||||
:param list(str) or str ignore_m2m: list of m2m tables ignored to remove. Use ``"*"`` to ignore
|
||||
all m2m tables
|
||||
|
||||
.. `[source] <https://github.com/odoo/upgrade-util/blob/master/src/util/models.py#L203>`_
|
||||
.. method:: rename_model(cr, old, new, rename_table=True)
|
||||
|
||||
Rename a model and its references from ``old`` to ``new``.
|
||||
|
||||
:param str old: current name of the model to rename
|
||||
:param str new: new name of the model to rename
|
||||
:param bool rename_table: whether the model's table is renamed
|
||||
|
||||
.. `[source] <https://github.com/odoo/upgrade-util/blob/master/src/util/models.py#L323>`_
|
||||
.. method:: merge_model(cr, source, target, drop_table=True, fields_mapping=None, ignore_m2m=())
|
||||
|
||||
Merge the references from ``source`` model into ``target`` model and removes ``source`` model and
|
||||
its references. By default, only the fields with the same name in both models are mapped.
|
||||
|
||||
.. warning::
|
||||
This function does not move the records from ``source`` model to ``target`` model.
|
||||
|
||||
:param str source: name of the source model of the merge
|
||||
:param str target: name of the destination model of the merge
|
||||
:param bool drop_table: whether the source model's table is dropped
|
||||
:param dict fields_mapping: Dictionary ``{"source_model_field_1": "target_model_field_1", ...}``
|
||||
mapping fields with different names on both models
|
||||
:param list(str) or str ignore_m2m: list of m2m tables ignored to remove from source model.
|
||||
|
||||
Modules
|
||||
-------
|
||||
|
||||
.. `[source] <https://github.com/odoo/upgrade-util/blob/master/src/util/modules.py#L218>`_
|
||||
.. method:: remove_module(cr, module)
|
||||
|
||||
Uninstall and remove a module and its references from the database.
|
||||
|
||||
:param str module: name of the module to remove
|
||||
|
||||
.. `[source] <https://github.com/odoo/upgrade-util/blob/master/src/util/modules.py#L263>`_
|
||||
.. method:: rename_module(cr, old, new)
|
||||
|
||||
Rename a module and its references from ``old`` to ``new``.
|
||||
|
||||
:param str old: current name of the module to rename
|
||||
:param str new: new name of the module to rename
|
||||
|
||||
.. `[source] <https://github.com/odoo/upgrade-util/blob/master/src/util/modules.py#L323>`_
|
||||
.. method:: merge_module(cr, old, into, update_dependers=True)
|
||||
|
||||
Move all references of module ``old`` into module ``into``.
|
||||
|
||||
:param str old: name of the source module of the merge
|
||||
:param str into: ame of the destination module of the merge
|
||||
:param bool update_dependers: whether the dependencies of modules that depends on ``old`` are
|
||||
updated
|
||||
|
||||
ORM
|
||||
---
|
||||
|
||||
.. `[source] <https://github.com/odoo/upgrade-util/blob/master/src/util/orm.py#L43>`_
|
||||
.. method:: env(cr)
|
||||
|
||||
Create a new environment from the cursor.
|
||||
|
||||
.. warning::
|
||||
This function does NOT empty the cache maintained on the cursor for superuser with an empty
|
||||
environment. A call to `invalidate_cache` will most probably be necessary every time you
|
||||
directly modify something in database.
|
||||
|
||||
:return: The new environment
|
||||
:rtype: :class:`~odoo.api.Environment`
|
||||
|
||||
.. `[source] <https://github.com/odoo/upgrade-util/blob/master/src/util/orm.py#L218>`_
|
||||
.. method:: recompute_fields(cr, model, fields, ids=None, logger=_logger, chunk_size=256, strategy="auto")
|
||||
|
||||
Recompute field values. Possible strategies to process the recomputation:
|
||||
|
||||
- ``flush``: Flush the recomputation when it's finished
|
||||
- ``commit``: Commit the recomputation when it's finished
|
||||
- ``auto``: The function chooses the best alternative based on the number of records to recompute
|
||||
and the fields traceability
|
||||
|
||||
:param str model: model name of the field(s) to recompute
|
||||
:param list(str) fields: list of field names to recompute
|
||||
:param list(int) ids: list of record IDs to recompute
|
||||
:param logger: Logger used to print the progress of the function
|
||||
:type logger: :class:`logging.Logger`
|
||||
:param int chunk_size: size of the chunk used to split the records for better processing
|
||||
:param str strategy: strategy used to process the recomputation
|
||||
|
||||
Records
|
||||
-------
|
||||
|
||||
.. `[source] <https://github.com/odoo/upgrade-util/blob/master/src/util/records.py#L612>`_
|
||||
.. method:: ref(cr, xmlid)
|
||||
|
||||
Return the id corresponding to the given :term:`xml_id <external identifier>`.
|
||||
|
||||
:param str xml_id: Record xml_id, under the format ``<module.id>``
|
||||
:return: Found record id, if any
|
||||
:rtype: int or `None`
|
||||
|
||||
.. `[source] <https://github.com/odoo/upgrade-util/blob/master/src/util/records.py#L281>`_
|
||||
.. method:: remove_record(cr, name)
|
||||
|
||||
Remove a record and its references corresponding to the given
|
||||
:term:`xml_id <external identifier>`.
|
||||
|
||||
:param str name: record xml_id, under the format ``<module.id>``
|
||||
|
||||
.. `[source] <https://github.com/odoo/upgrade-util/blob/master/src/util/records.py#L548>`_
|
||||
.. method:: rename_xmlid(cr, old, new, noupdate=None, on_collision="fail")
|
||||
|
||||
Rename the :term:`external Identifier` of a record. Possible actions to take if the external
|
||||
Identifier already exists on the database:
|
||||
|
||||
- ``fail``: raise ``MigrationError`` and prevent renaming
|
||||
- ``merge``: renames the external Identifier and removes the old one
|
||||
|
||||
:param str old: current xml_id of the record, under the format ``<module.id>``
|
||||
:param str new: new xml_id of the record, under the format ``<module.id>``
|
||||
:param bool noupdate: value to set on the ir_model_data record ``noupdate`` field
|
||||
:param str on_collision: action to take if the xml_id already exists
|
||||
|
||||
.. `[source] <https://github.com/odoo/upgrade-util/blob/master/src/util/records.py#L652>`_
|
||||
.. method:: ensure_xmlid_match_record(cr, xmlid, model, values)
|
||||
|
||||
Match a record with an xmlid by creating or updating the external identifier.
|
||||
|
||||
This function is useful when migrating in-database records into a custom module, to create the
|
||||
record's xmlid before the module is updated and avoid duplication.
|
||||
|
||||
:param str xmlid: record xml_id, under the format ``<module.id>``
|
||||
:param str model: model name of the record
|
||||
:param dict values: Dictionary ``{"fieldname_1": "value_1", ...}`` mapping fields and values to
|
||||
search for the record to update. For example:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
values = {"id": 123}
|
||||
values = {"name": "INV/2024/0001", company_id: 1}
|
||||
|
||||
:return: the :term:`xml_id <external identifier>` of the record.
|
||||
:rtype: str
|
||||
|
||||
.. `[source] <https://github.com/odoo/upgrade-util/blob/master/src/util/records.py#L720>`_
|
||||
.. method:: update_record_from_xml(cr, xmlid, reset_write_metadata=True, force_create=True, from_module=None, reset_translations=())
|
||||
|
||||
Update a record based on its definition in the :doc:`/developer/reference/backend/data`.
|
||||
|
||||
Useful to update ``noupdate`` records, in order to reset them for the upgraded version.
|
||||
|
||||
:param str xmlid: record xml_id, under the format ``<module.id>``
|
||||
:param bool reset_write_metadata: whether the metadata before the record update is kept
|
||||
:param bool force_create: whether the record is created if it does not exist
|
||||
:param str from_module: name of the module from which to update the record. Useful when the
|
||||
record is rewritten in another module.
|
||||
:param set of str reset_translations: set of field names whose translations get reset
|
Loading…
Reference in New Issue
Block a user