[FIX] Upgrade documentation: Review changes by CHS

Author: augustoPerez

content/developer/howtos/upgrade/migration_scripts.rst renamed to content/developer/howtos/upgrade/upgrade_scripts.rst

@@ -1,8 +1,8 @@
-=================
-Migration scripts
-=================
+===============
+Upgrade scripts
+===============
 
-A migration script is a Python file containing a function called :file:`migrate`, which the upgrade
+An upgrade script is a Python file containing a function called :file:`migrate`, which the upgrade
 process invokes during the update of a module.
 
 The :file:`migrate` function receives two parameters:
@@ -13,14 +13,14 @@ The :file:`migrate` function receives two parameters:
 Typically, this function executes one or multiple SQL queries and can also access Odoo's ORM, as
 well as the :doc:`../upgrade/upgrade_util`.
 
-As described in :ref:`upgrade_custom/upgraded_database/migrate_data`, you might have to use
-migration scripts to reflect changes from the source code to their corresponding data.
+As described in :ref:`upgrade_custom/upgraded_database/migrate_data`, you might have to use upgrade
+scripts to reflect changes from the source code to their corresponding data.
 
 
-Writing migration scripts
+Writing upgrade scripts
 =========================
 
-To write what we refer as a **custom migration script**, the path of the file should follow this
+To write what we refer as a **custom upgrade script**, the path of the file should follow this
 template: :file:`<module_name>/migrations/<major_version>.<minor_version>/{pre|post|end}-*.py`.
 
 Follow this steps to create the directory's structure and the Python file:
@@ -34,13 +34,13 @@ Follow this steps to create the directory's structure and the Python file:
       - :file:`<minor_version>` corresponds to the updated version declared on the module's
         manifest.
 
-      Migration scripts are only executed when the module is being updated. Therefore, the
+      Upgrade scripts are only executed when the module is being updated. Therefore, the
       :file:`minor_version` set in the directory needs to be higher than the module's installed
       version and equal or lower to the updated version of the module.
       For example, in an `Odoo 16` database, with a custom module installed in version `1.1`, and an
       updated module version equal to `1.2`; the version directory should be `16.0.1.2`.
    #. Create a :file:`Python file` inside the :file:`<version>` directory named according to the
-      :ref:`Phase <upgrade/migration-scripts/phases>` on which it needs to be executed. It should
+      :ref:`Phase <upgrade/upgrade-scripts/phases>` on which it needs to be executed. It should
       follow the template `{pre|post|end}-*.py`. The file name will determine the order in which it
       is executed for that module, version and phase.
    #. Create a :file:`migrate` function in the Python file that receives as parameters
@@ -49,7 +49,7 @@ Follow this steps to create the directory's structure and the Python file:
 
 .. example::
 
-   Directory structure of a migration script for a custom module named `awesome_partner` upgraded
+   Directory structure of an upgrade script for a custom module named `awesome_partner` upgraded
    to version `2.0.0` on Odoo 17
 
    .. code-block:: text
@@ -59,7 +59,7 @@ Follow this steps to create the directory's structure and the Python file:
       |   |-- 17.0.2.0.0/
       |   |   |-- pre-exclamation.py
 
-   Two migration scripts examples with the content of the :file:`pre-exclamation.py`, file adding
+   Two upgrade scripts examples with the content of the :file:`pre-exclamation.py`, file adding
    "!" at the end of partners' names:
 
    .. code-block:: python
@@ -94,15 +94,15 @@ Follow this steps to create the directory's structure and the Python file:
    to access the ORM. Check the documentation to find out more about this library.
 
 
-Running and testing migration scripts
+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 migration scripts on this platform.
+      databases, it is not possible to run upgrade scripts on this platform.
 
    .. group-tab:: Odoo.sh
 
@@ -111,9 +111,9 @@ Running and testing migration scripts
 
       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 migration scripts.
+      This update includes the execution of the upgrade scripts.
 
-      When upgrading the production database, the execution of the migration scripts is also part of
+      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
@@ -129,9 +129,9 @@ Running and testing migration scripts
          to call the CLI depends on how you installed Odoo.
 
 
-.. _upgrade/migration-scripts/phases:
+.. _upgrade/upgrade-scripts/phases:
 
-Phases of migration scripts
+Phases of upgrade scripts
 ===========================
 
 The upgrade process consists of three phases for each version of each module:
@@ -140,7 +140,7 @@ The upgrade process consists of three phases for each version of each module:
   #. The post-phase, after the module and its dependencies are loaded and upgraded.
   #. The end-phase, after all modules have been loaded and upgraded for that version.
 
-Migration scripts are grouped according to the first part of their filenames into the corresponding
+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.
 
 .. note::

content/developer/howtos/upgrade/upgrade_util.rst

@@ -4,7 +4,7 @@ Upgrade Util package
 
 The `Upgrade Util package <https://github.com/odoo/upgrade-util/>`_ is a library that contains
 helper functions to facilitate the writing of upgrade scripts. This package, used by Odoo for the
-migration scripts of standard modules, provides reliability and helps speed up the upgrade process:
+upgrade scripts of standard modules, provides reliability and helps speed up the upgrade process:
 
 - The helper functions make sure the data is consitent in the database.
 - It takes care of indirect references of the updated records.
@@ -36,12 +36,12 @@ the custom repository. For this, add the following line inside the file::
 Using the Util package
 ======================
 
-Once installed, the following packages are available for the migration scripts:
+Once installed, the following packages are available for the upgrade scripts:
 
 - :file:`odoo.upgrade.util`: the helper themself.
 - :file:`odoo.upgrade.testing`: base TestCase classes.
 
-To use it in migration scripts, simply import it:
+To use it in upgrade scripts, simply import it:
 
 .. code-block:: python
 
@@ -63,7 +63,7 @@ helper functions.
 
 .. note::
    All util functions receive :file:`cr` as a parameter. This refers to the database cursor. Use the
-   one received as a parameter in the :doc:`migration_scripts`.
+   one received as a parameter in the :doc:`upgrade_scripts`.
 
 Fields
 ------
@@ -277,7 +277,7 @@ Records
 .. _upgrade/util/update_record_from_xml:
 
 .. `[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=False][, from_module=None][, reset_translations=()])
+.. 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 on the :doc:`../../reference/backend/data`. Useful to
    update ``noupdate`` records, in order to reset them for the upgraded version.
@@ -286,7 +286,7 @@ Records
    :param bool reset_write_metadata: if ``True``, the metadata before the record update is kept
       (default: ``True``)
    :param bool force_create: if ``True``, creates the record if it does not exist. (default:
-      ``False``)
+      ``True``)
    :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.

content/developer/howtos/upgrade_custom_db.rst

@@ -200,12 +200,12 @@ 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 :doc:`upgrade/migration_scripts` to
-reflect changes from the source code to their corresponding data. Together with the Migration
+During the upgrade of the custom modules, you might have to use :doc:`upgrade/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:`upgrade/upgrade_util` 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
+  external identifiers) should be renamed using upgrade scripts to avoid data loss during the
   module upgrade. See also: :ref:`util.rename_field <upgrade/util/rename_field>`,
   :ref:`util.rename_model <upgrade/util/rename_model>`, :ref:`util.rename_xmlid
   <upgrade/util/rename_xmlid>`.
@@ -216,9 +216,9 @@ scripts, you can also make use of the :doc:`upgrade/upgrade_util` and its helper
    .. 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 a migration script to move the data from one table to the other. Take into account
+      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/migration-scripts/phases`).
+      :ref:`upgrade/upgrade-scripts/phases`).
 
       .. spoiler::
 
@@ -234,9 +234,9 @@ scripts, you can also make use of the :doc:`upgrade/upgrade_util` and its helper
                   """
                )
 
-         Check  the documentation for more information on :doc:`upgrade/migration_scripts`.
+         Check the documentation for more information on :doc:`upgrade/upgrade_scripts`.
 
-Migration scripts can also be used to:
+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.
@@ -261,10 +261,10 @@ 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.
+  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
+  data that needs to be updated due to changes in the new version, we recommend to use upgrade
   scripts to do so. See also: :ref:`util.update_record_from_xml
   <upgrade/util/update_record_from_xml>`.