diff --git a/content/administration.rst b/content/administration.rst index 68c18e44bc..6afb471a43 100644 --- a/content/administration.rst +++ b/content/administration.rst @@ -18,5 +18,4 @@ These guides provide instructions on how to install, maintain and upgrade Odoo d administration/install administration/maintain - administration/upgrade administration/odoo_sh diff --git a/content/administration/maintain/odoo_online.rst b/content/administration/maintain/odoo_online.rst index 9d76cd480c..dfa80dd83e 100644 --- a/content/administration/maintain/odoo_online.rst +++ b/content/administration/maintain/odoo_online.rst @@ -31,7 +31,7 @@ Trigger a database upgrade. .. seealso:: For more information about the upgrade process, check out the :doc:`Odoo Online upgrade - documentation <../upgrade/odoo_online>`. + documentation <../../upgrade/request/odoo_online>`. .. _odoo_online/duplicate: diff --git a/content/administration/maintain/supported_versions.rst b/content/administration/maintain/supported_versions.rst index 4d71fac7f7..b1612365cc 100644 --- a/content/administration/maintain/supported_versions.rst +++ b/content/administration/maintain/supported_versions.rst @@ -12,7 +12,7 @@ Odoo provides support and bug fixing **for the 3 last major versions** of Odoo. ` hosting every two months. Odoo Online users can then benefit from the latest features of Odoo. - - Admins of Odoo Online databases are invited to :doc:`upgrade <../upgrade>` them regularly. + - Admins of Odoo Online databases are invited to :doc:`upgrade ` them regularly. - Online versions are *not* released for Odoo.sh and On-Premise installations. - Online versions are listed below as *SaaS*. diff --git a/content/administration/odoo_sh/getting_started/branches.rst b/content/administration/odoo_sh/getting_started/branches.rst index 6e566acb5e..51d27b9ac1 100644 --- a/content/administration/odoo_sh/getting_started/branches.rst +++ b/content/administration/odoo_sh/getting_started/branches.rst @@ -295,7 +295,7 @@ Upgrade Available for production and staging branches for valid projects. .. seealso:: - :doc:`Upgrade - Odoo.sh <../../upgrade/odoo_sh>` + :doc:`Upgrade - Odoo.sh <../../../upgrade/request/odoo_sh>` .. _odoosh-gettingstarted-branches-tabs-settings: diff --git a/content/administration/upgrade.rst b/content/administration/upgrade.rst deleted file mode 100644 index 3695b98e77..0000000000 --- a/content/administration/upgrade.rst +++ /dev/null @@ -1,264 +0,0 @@ -:show-content: - -.. |assistance-contact| replace:: - If you need Odoo assistance on this matter, please get in touch with your Odoo Account Manager or - our `Sales department`_. -.. _Sales department: mailto:sales@odoo.com - -======= -Upgrade -======= - -.. toctree:: - :titlesonly: - - upgrade/odoo_online - upgrade/odoo_sh - upgrade/on_premise - upgrade/faq - -An upgrade is switching to a newer version of Odoo (e.g., Odoo 14.0 to Odoo 15.0). - -An upgrade does not cover: - -* Changing :ref:`editions ` (i.e., Community to Enterprise edition) -* Switching :ref:`hosting type ` (i.e., On-Premise to Odoo Online - or Odoo.sh) -* Migration from another ERP to Odoo - -.. note:: |assistance-contact| - -.. seealso:: - - :ref:`upgrade/sla` - -.. _upgrade/process-workflow: - -Process workflow -================ - -The upgrade process in a nutshell: - -#. You create a test upgrade request. -#. Odoo processes the request automatically by running the database through an upgrade script, which - takes between 20 and 120 minutes. -#. Odoo delivers a test database. -#. You test your database for possible discrepancies (see :ref:`upgrade/test-guidance`). -#. If there are any discrepancies, you report them to the Upgrade support team via the help portal - (see :ref:`upgrade/test-assistance`). -#. We fix the issues and send you a new test database. -#. Once you have completed the testing and are happy with the result, you decide on a date and time - when you stop users from accessing Odoo, freeze all data entries, and create an upgrade request - for the production upgrade. -#. Odoo delivers the production database through the automated process. -#. You restore it in your Production environment a few short hours later and continue working on the - newly upgraded database (this is done automatically on Odoo Online). - -.. seealso:: - - :doc:`Upgrade process for Odoo Online ` - - :doc:`Upgrade process for Odoo.sh ` - - :doc:`Upgrade process for On-Premise ` - -.. _upgrade/testing-phase: - -Testing -======= - -This phase allows you to review an upgraded version of your database without affecting your -production database in any way. We suggest that you run the test upgrade process at least once, but -you can do it as many times as you need (one at a time). - -Once you receive your upgraded test database, check that all data, processes, and functionality are -still correct and working as expected. - -If you do find discrepancies, :ref:`report your issues ` and :ref:`request -a new test database ` when the reported issues are fixed in the upgrade -script. - -If you do not find any discrepancies, you can move on to the upgrade of your production database. - -.. important:: - A test database is only intended for testing and remains completely unrelated to your present or - future production database. Any data you add, or changes you make, will not be reflected in your - upgraded production database. - -.. note:: - Test databases are neutered and features are disabled to prevent them from having an impact on - the production database: - - #. The serial number of the database is modified (to prevent it from sending information as if it - was the production database). - #. The :ref:`base URL of the database ` is reset to - ``http://localhost:8069`` and the email domain to ``localhost``. - #. Scheduled actions are disabled (the calendar synchronization, the bank statement - synchronization, the planned automated actions, the fetching of incoming mail servers, etc.). - #. Outgoing mail servers are disabled by archiving the existing ones and adding a - fake/non-working one. - #. Payment providers and delivery carriers are reset to test environment. - #. Accounting localization Electronic Data Interchange (EDI) services are disabled. - #. A system parameter is set to tell the database has been neutered. - -.. _upgrade/test-db-request: - -Request a test database -======================= - -Follow the instructions available per hosting type on the `website form -`_ and select *Testing* purpose. - -.. image:: upgrade/test-purpose.png - :align: center - :alt: Selection of the "Testing" purpose in the upgrade form on Odoo - -.. _upgrade/test-guidance: - -Test guidance -============= - -Every business and organization has its own operational needs and has to test its specific Odoo -database individually. We recommend you look at `the test scenario -`_ for further -information. - -.. todo:: change link "test scenario" once the related doc is published - -.. _upgrade/test-assistance: - -Assistance ----------- - -If you encounter an issue in the **test database**, please get in touch with Odoo Upgrade Support -via the `Odoo Support page `_. - -Under the *Ticket Description* section, select *An issue related to my upgrade* ticket type. - - .. image:: upgrade/test-assistance.png - :align: center - :alt: Selection of "An issue related to my upgrade" as Ticket Type in the support form on Odoo - - .. warning:: - If you choose another *Ticket Description* type, the request will be redirected to another - team. This will slow down the processing and response time. - -Please provide as much detail as you can (i.e., videos and screenshots to illustrate your issue). -This will avoid clarifying questions and speed up the resolution process significantly. - -.. note:: - * The purpose of the test phase is not to correct existing data or configurations in your - database. - * |assistance-contact| - -.. _upgrade/steps-production: - -The production launch -===================== - -The production upgrade request is when you decide to upgrade your current database with all your -production data (invoices, VAT returns, inventories, current orders) to a new version of your -choice. - -After your :ref:`tests ` are completed to your satisfaction, submit the -request to upgrade your production database via our `website form `_. -Select *Production* purpose. - -.. important:: - Going into production without first testing may lead to: - - - business interruptions (e.g., no longer having the possibility to validate an action) - - poor customer experiences (e.g., an eCommerce website that does not work correctly) - -.. _upgrade/production-assistance: - -Assistance ----------- - -If you encounter issues or problems in the **production database**, please get in touch with **Odoo -Support**: - -#. Connect to our `Odoo Support page `_. -#. Under the *Ticket Description* section, select the appropriate type related to your issue but - **do not select** the option *An issue related to my upgrade*. - - .. note:: - After upgrading to production, the support will be provided by the Support team instead of the - Upgrade team. - -#. Please provide as much detail as you can (i.e., videos and screenshots to illustrate your issue). - This will avoid clarifying questions and speed up the resolution process significantly. - - .. warning:: - If you choose *An issue related to my upgrade* as ticket type, the request will be redirected - to another team than the support one and will slow down the processing and response time. - -.. _upgrade/assistance: - -Help -==== - -.. _upgrade/contact: - -Contact our upgrade service support ------------------------------------ - -Should you have any more questions about the upgrade, do not hesitate to send a message to `Odoo -Upgrade Team `_. We will be happy to answer it as soon as possible. - -.. _upgrade/supported-versions: - -Supported versions ------------------- - -Please note that Odoo provides support and bug fixing only for the three last major versions of -Odoo. - -This is a factor to take into consideration before upgrading. If you are on an older version, we -suggest you to prefer the most recent version to benefit from longer support (before having to -upgrade again). - -.. seealso:: - :doc:`maintain/supported_versions` - -.. _upgrade/sla: - -Service-level agreement (SLA) -============================= - -With Odoo Enterprise, upgrading a database to the most recent version of Odoo is **free**, including -any support required to rectify potential discrepancies in the upgraded database. - -Information about the upgrade services included in the Enterprise Licence is available in the -:ref:`Odoo Enterprise Subscription Agreement `. However, this section clarifies what -upgrade services you can expect. - -Upgrade services covered by the SLA ------------------------------------ - -Databases hosted on Odoo's cloud platforms (Odoo Online and Odoo.sh) or self-hosted (On-Premise) can -benefit from upgrade services at all times for: - -- the upgrade of all **standard applications**; -- the upgrade of all **customizations created with the Studio app**, as long as Studio is still - installed and the respective subscription is still active; and -- the upgrade of all **developments and customizations covered by a maintenance of customizations - subscription**. - -Upgrade services are limited to the technical conversion and adaptation of a database (standard -modules and data) to make it compatible with the version targeted by the upgrade. - -Upgrade services not covered by the SLA ---------------------------------------- - -The following upgrade-related services are **not** included: - -- the **cleaning** of pre-existing data and configurations while upgrading; -- the upgrade of **custom modules created in-house or by third parties**, including Odoo partners; -- lines of **code added to standard modules**, i.e., customizations created outside the Studio app, - code entered manually, and :ref:`automated actions using Python code - `; and -- **training** on using the upgraded version's features and workflows. - -.. note:: |assistance-contact| - -.. seealso:: - - :doc:`Upgrade FAQ ` - - :doc:`Odoo.sh documentation ` - - :doc:`Supported Odoo versions ` diff --git a/content/administration/upgrade/test-assistance.png b/content/administration/upgrade/test-assistance.png deleted file mode 100644 index 2fac7cf86e..0000000000 Binary files a/content/administration/upgrade/test-assistance.png and /dev/null differ diff --git a/content/applications/finance/fiscal_localizations/egypt.rst b/content/applications/finance/fiscal_localizations/egypt.rst index 1ad9b65582..acfd2824b1 100644 --- a/content/applications/finance/fiscal_localizations/egypt.rst +++ b/content/applications/finance/fiscal_localizations/egypt.rst @@ -32,11 +32,11 @@ Odoo is compliant with the **Egyptian Tax Authority (ETA) e-invoicing** requirem .. important:: Egyptian e-invoicing is available from Odoo 15.0. If needed, :doc:`upgrade - ` your database. + ` your database. .. seealso:: - `Video: Egypt E-invoicing `_ - - :doc:`/administration/upgrade` + - :doc:`/upgrade` .. _egypt/e-invoicing-eta-portal: diff --git a/content/index.rst b/content/index.rst index 952a7a6a79..77b510f897 100644 --- a/content/index.rst +++ b/content/index.rst @@ -9,5 +9,6 @@ Odoo Documentation applications administration + upgrade developer contributing diff --git a/content/upgrade.rst b/content/upgrade.rst new file mode 100644 index 0000000000..4217a1617f --- /dev/null +++ b/content/upgrade.rst @@ -0,0 +1,23 @@ +:nosearch: +:show-content: +:hide-page-toc: +:show-toc: + +.. |assistance-contact| replace:: + If you need Odoo assistance on this matter, please get in touch with your Odoo Account Manager or + our `Sales department`_. +.. _Sales department: mailto:sales@odoo.com + +======= +Upgrade +======= + +.. toctree:: + + upgrade/introduction + upgrade/preparing + upgrade/request + upgrade/advanced + upgrade/assistance + upgrade/faq + upgrade/sla diff --git a/content/upgrade/advanced.rst b/content/upgrade/advanced.rst new file mode 100644 index 0000000000..a9d512fa83 --- /dev/null +++ b/content/upgrade/advanced.rst @@ -0,0 +1,14 @@ +======== +Advanced +======== + +.. toctree:: + :titlesonly: + + advanced/upgrade_process + advanced/odoo_shell + advanced/util_package + advanced/migration_scripts + advanced/upgrade_data + advanced/upgrade_studio + advanced/upgrade_custom_code diff --git a/content/upgrade/advanced/migration_scripts.rst b/content/upgrade/advanced/migration_scripts.rst new file mode 100644 index 0000000000..feb78b44ff --- /dev/null +++ b/content/upgrade/advanced/migration_scripts.rst @@ -0,0 +1,100 @@ +============================ +What are migration scripts ? +============================ + +Migration scripts form the backbone of Odoo's upgrade process. Each migration script is a Python file containing a function called "migrate," which the upgrade process invokes at the appropriate time. Typically, this function executes one or multiple SQL queries and can also access Odoo's ORM, thanks to the "util" package TODO: link to util package. + +The standard upgrade process involves a sequence of migration scripts, each responsible for upgrading a specific part of a module's data. When all these scripts have been executed, the data in the PSQL database aligns with the source code of Odoo for the targetted version. + +.. example:: + Between Odoo 15 and Odoo 16, the `sale.subscription` model was merged into `sale.order` in the standard code of Odoo. This change required the development of standard migration scripts to transfer rows from the `sale_subscription` PSQL table to the `sale_order` table, ensuring no data is lost. Then, once the standard data has been migrated, the table `sale_subscription` gets removed by another standard migration script. + +In this documentation, we make a distinction between *standard* and *custom* migration scripts. Standard migration scripts are those that are part of the source code of Odoo that are developed and maintained by Odoo S.A.. *Custom* migration scripts are any migration scripts that are developed for a custom module, that is a module not created or maintained by the R&D team Odoo S.A.. There is no difference in the code of a standard or custom migration script, but the distinction is important for the upgrade process. + +.. seealso:: + `Migrations in Django `_ + + +.. example:: + + A migration script to add an exclamation mark at the end of the name of each partner in PSQL would look like this: + + .. 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) + + +In summary, the Odoo Shell allows you to execute Python instructions interactively, enabling access to any model and record using the ORM. Migration scripts, on the other hand, are pre-defined Python files executed at specific points during an upgrade. + +The Importance of Placement +--------------------------- +Unlike the Odoo Shell, allowing you to run code on your database at will, migration scripts must be prepared before launching your Odoo instance and are executed at precise moments during module upgrades. These scripts follow a structured pattern: + +`/migrations/./{pre|post|end}-*.py`` + + +This complex structure allows an exact ordering of the execution of all the stnadard migration scripts during the upgrade process. They are neatly organized in various folders based on the module, major version (Odoo version), minor version (module version), and ordered by their names, split in 3 phases. + +Module name +=========== + +The module folder is the first part of the file path, found in the "addons/" or "enterprise/" folder of the source code of Odoo. For instance, all migration scripts written for the Accounting module of Odoo, named "account," are placed under `account/migrations/`. + +Major version +============= + +The second part is pretty simple as the major version is straightforward. If the script must run when the database is running Odoo 16, then the `` has to be `16.0`. + +.. important:: + Migrations scripts for a specific version of Odoo will be ran in that version. Therefore the script cannot use features that are not available in that version, such as certain features of Python, or referencing fields or methods that have been changed. + +Minor version +============= + +The minor version corresponds to your module's version in the manifest. It is independant of the major version. + +.. example:: + The Accounting (`account`) module of Odoo 16 is currently in the version `1.2` as written in `its manifest `_. Therefore, a migration script that must be executed when upgrading the account module from version 1.1 to version 1.2 in Odoo 16 must be placed here in `account/migrations/16.0.1.2` + + + +Migration script name and the 3 phases +====================================== + +TODO be reviewed by rd-upgrade. + +The upgrade process consists of three phases for each version of each module. It starts with the pre-phase, followed by post- and then end-. Migration scripts are grouped according to the first part of their filenames into the corresponding phase. + +The pre-phase is executed before the module and its dependencies are loaded, meaning that you cannot use the ORM to access any model or record, but executing PSQL queries in that phase is possible. The post-phase is executed after the module and its dependencies are loaded and upgraded. At that time, the ORM becomes available and you can refer any model or record. + +The end-phase is a little bit different, as it is executed after all modules have been upgraded for the major version. This phase is useful to perform operations that require the whole database to be upgraded, or to perform operations for which the order is not important such as modifying views. + +Migration scripts are grouped according to the first part of their filenames into the corresponding phase. So for example a file named `pre-upgrade_data.py` will execute before `post-do_upgrade_data.py` regardless of their lexical order. In each phase, files are then executed according to their lexical order. + +.. example:: + The following example shows the execution order of migration scripts with various names in various phases: + - pre-zzz.py + - pre-~do_something.py + - post--testing.py + - post-01-zzz.py + - post-migrate.py + - post-other_module.py + - post-~migrate.py + - end--migrate.py + - end-01-migrate.py + - end-aaa.py + - end-~migrate.py + +The placement of the scripts can be important to better organize your custom migration scripts. Furthermore, it allows Upgrade technician to inject custom migration scripts in the standard upgrade process to restore fields or views when reported with our :doc:`Assistance page `. diff --git a/content/upgrade/advanced/odoo_shell.rst b/content/upgrade/advanced/odoo_shell.rst new file mode 100644 index 0000000000..6628d1d3a8 --- /dev/null +++ b/content/upgrade/advanced/odoo_shell.rst @@ -0,0 +1,25 @@ +========== +Odoo Shell +========== + +If you're familiar with Odoo, you probably know the user-friendly Graphical User Interface (GUI), which is the web page where you carry out your operations in Odoo, commonly referred to as the web client or front-end. + +.. image:: odoo_shell/odoo-web-client.png + :alt: The Odoo web client we all know and love + :align: center + +The front-end simplifies complex operations like invoice validation, product transfers, and more, often triggered by a single button click. However, beneath this simplicity lies a significant amount of code execution, sometimes involving hundreds of lines! + +Occasionally, you might face situations where you need to perform a straightforward operation on numerous records, such as checking a checkbox for each project in the Project App. Manually navigating menus for such tasks can be time-consuming and tedious 🥱 + +At Odoo, we value efficiency, and this is where the "Odoo Shell" comes into play. For seasoned Odoo users, it's a handy trick. The Odoo Shell allows direct interaction with the Object-Relational-Mapping (ORM), enabling you to manipulate data almost as if you were working directly within Odoo's source code. With just a few lines of code, you can, for instance, update all contact names in your database by adding an exclamation mark to each. This operation would take seconds in the Odoo Shell but potentially hours in the front-end. The Odoo Shell is a true blessing ! 🙏 + +.. image:: odoo_shell/odoo-shell-example.png + :alt: An example of the use of the shell of Odoo : multiple lines of Python code that change the name of each partner to add an exclamation mark at the end of each partner + :align: center + +The Odoo Shell is essentially an extension of the `IPython shell `_, directly connected to the Odoo database. While it's somewhat similar to creating a server or automated action and executing it, the Odoo Shell offers the flexibility to write code incrementally, exploring Odoo's inner workings. It's a valuable tool for developing migration scripts, allowing you to test the code you wrote before starting the whole upgrade process instead of risking a full database upgrade only to discover a minor coding error. + +Accessing the Odoo Shell depends on your hosting type. For On-Premise databases, you can add the "shell" keyword as the first parameter when executing your instance. For instance, if you use `./odoo-bin -d my_database`, you can simply use `./odoo-bin shell -d my_database`. On Odoo SH, it's even simpler, as you have direct access to a bash terminal via the "Shell" tab. Once in the terminal, you can run the command `odoo-bin shell` to gain immediate access to your database's Odoo Shell. Convenient, isn't it? + +The Odoo shell is not applicable to Odoo Online since users only have access to the web client, and not the server running their Odoo database. diff --git a/content/upgrade/advanced/odoo_shell/odoo-shell-example.png b/content/upgrade/advanced/odoo_shell/odoo-shell-example.png new file mode 100644 index 0000000000..989a0d3edc Binary files /dev/null and b/content/upgrade/advanced/odoo_shell/odoo-shell-example.png differ diff --git a/content/upgrade/advanced/odoo_shell/odoo-web-client.png b/content/upgrade/advanced/odoo_shell/odoo-web-client.png new file mode 100644 index 0000000000..bf55f775e5 Binary files /dev/null and b/content/upgrade/advanced/odoo_shell/odoo-web-client.png differ diff --git a/content/upgrade/advanced/upgrade_custom_code.rst b/content/upgrade/advanced/upgrade_custom_code.rst new file mode 100644 index 0000000000..8b084ee489 --- /dev/null +++ b/content/upgrade/advanced/upgrade_custom_code.rst @@ -0,0 +1,64 @@ +============================= +Upgrading your custom modules +============================= + +If your Odoo database has custom modules installed, you will have to make sure that they are compatible with the new version of Odoo. The standard modules developed by Odoo S.A. exist in each version of Odoo starting from the version of their creation since they are upgraded to be part of the standard package of Odoo for the next version. + +However, custom modules developed by third parties have to be maintained by their developers. If you are the developer of a custom module, you will have to upgrade its code to make it compatible with the new version of Odoo. Otherwise, you should ask the developer responsible for its maintenance to create a version of the module compatible with the new version of Odoo. + +There are many ways to go about upgrading your custom modules. Here are the recommended main steps to follow: + +- Initialize a database with the new version of Odoo +- Install your module in the new database +- Fix the errors during the installation and during the testing. + + +Making your custom module installable +------------------------------------- + +The first step of upgrading a custom module is to make it installable in the new version of Odoo. To do so, modules must be made compatible with that version of Odoo. This means that all references to fields, models, views, methods, reports, etc. must be updated to match the new version of Odoo. + +.. example:: + Between Odoo 14 and Odoo 15, the field `user_id` of the model `project.task` has been renamed to `user_ids`. Therefore, when upgrading a module from before Odoo 14 to after Odoo 15, any reference of `user_id` must be changed to `user_ids` in the code of the module. + +This requires a static analysis of the code to find all the references of deprecated elements, but it can be also done by installing the module, and fixing the errors that occur during the installation. + +.. important:: + When changing the name of fields in the code, their data stored in a PSQL column must be moved with :doc:`migration scripts ` to the new column. Furthermore, fields can also be referenced in other parts of the database such as automated actions, views, reports, etc ... which can be stored in the database independently from the code. + + +Upgrading your fields and models inheritance +============================================= + +Finding the new name of a field or model after an upgrade can be quite challenging as it requires some investigation work. The best way to do so is to look at the properties of the fields and models in the current version of Odoo, and match them with the properties of the fields and models in the new version of Odoo. + +.. example:: + In Odoo 12 and before, the model `account.invoice` had a field named `refund_invoice_id` (`source code `_) which cannot be found in the new model `account.move` after Odoo 13. This field was actually renamed to `reversed_entry_id` during the upgrade process. It is possible to find this information by searching for another Many2one field in `account.move` that is related to `account.move` in the upgraded version of Odoo. + +The logs of the upgrade process can also be helpful to determine the corresponding field since some migration scripts will explicitely log the renaming. + +Models being renamed is more rare and usually easier to discover since there are not many models in an Odoo module. Therefore it is simply a matter of comparing the filenames of the models in the old and new version of Odoo. The :ref:`upgrade-faq/upgrade-report` can also contain useful information about the renaming of models. + +Upgrading your method overriding +================================ + +Just like fields and models, methods can also change between two versions of Odoo. For any override of standard method in a custom module, it is necessary to check if the method has been renamed or refactored in the new version of Odoo. + +It can sometimes be tricky to find its new name, especially since they are never logged in the upgrade process. The best way to find the new name of a method is to look at the source code of that method in the old version of Odoo to match it with the source code of the method in the new version of Odoo. This works wonderfully for methods that have simply been renamed, but it can be more difficult for methods that have been refactored. + +.. example:: + In Odoo 15, the model `sale.subscription` has a method `_prepare_invoice_data` (`source code `_) which has been renamed to `_prepare_invoice` in the model `sale.order` (`source code `_) + +It is very important to make sure to rename the method in the same way as it has been renamed in the new version of Odoo. This is because if a method calls its parent using `super()` in the code of a custom module, it will not match the method of the standard code of Odoo in its new version. This will lead to an error message appearing when the function is triggered which can be very difficult to predict. This is one of the reasons why it is very important to spend a significant amount of time in the testing phase of the upgrade process. + +.. _upgrade_views: + +Upgrading your view inheritance +================================ + +Views defined in the standard code of Odoo have an external identifier that corresponds to the attribute `id` of the `` tag of a view. It is very rare to have this external identifier change between two versions of Odoo, and can therefore be used to match + +Making your custom data compatible +---------------------------------- + +Now that your custom module works just as well in the new version of Odoo, the last step of upgrading it is to ensure that your custom data is compatible with the new version of the module. This is done with :doc:`Migration scripts ` diff --git a/content/upgrade/advanced/upgrade_data.rst b/content/upgrade/advanced/upgrade_data.rst new file mode 100644 index 0000000000..487eca50ee --- /dev/null +++ b/content/upgrade/advanced/upgrade_data.rst @@ -0,0 +1,91 @@ +============================= +Upgrading your data if needed +============================= + +Errors during upgrade : the different types +------------------------------------------- + +During the upgrade process for your database, you might encounter an error that prevents your upgrade request to be completed. By analyzing the logs and the error message, you can determine the type of error you are facing and deduce the solution to fix it. + +.. seealso:: + :ref:`reference/exceptions` + +Access Error +============ + +During the upgrade process, the user searching and modifying the data, as dictated by the migration scripts, is the user with ID=2 by default, which is the administrator of the database. If that user lacks certain access right, you might encounter this error `odoo.exceptions.AccessError: Due to security restrictions, you are not allowed to access '' () records.` + +.. example:: + `odoo.exceptions.AccessError: You are not allowed to access 'Applicant' (hr.applicant) records.` + + This error message means that the user with ID=2 does not have the access rights to read the records of the model `hr.applicant` (Recruitment app > Applications). It is the same error message that can appear when trying to access a record from the web interface, if the user does not have the access rights to read that record. + +Such an access error can arrise due to the fact that there are many situations in the code where data must be accessed regardless of which user is currently connected, such as with compute methods which can sometimes recomputed during the upgrade, by the administrator user. This is why, in Odoo, the administrator user with ID=2 must always have full access rights to all the models and data. + +.. figure:: /upgrade/advanced/upgrade_data/admin_access_rights.png + :width: 100% + :alt: Form view of the user with ID 2 which has the highest rights for all groups + + What the groups should look like for the admin user. If some groups are missing, you expose yourself to many potential issues during and after the upgrade process. + +Therefore, if you modified that user to match one of your actual Odoo user/employee instead of creating a new one from scratch, you expose yourself to many access errors if any access rights are taken away from that user. + +The solution is simply to give back all the default admin access rights and groups to that user. You can modify those access rights by going to Settings > Users & Companies and selecting the user with ID=2. Then, you will be able to modify all the groups under the "Access Rights" tab, giving that user the most powerful rights for each group + +.. seealso:: + :doc:`/applications/general/users/access_rights` + +Validation Error +================ + +This type of error is related to the various safeguards implemented everywhere in the code of Odoo, ensuring that your data does not have any inconsistency. Those error messages can be raised in the standard code of Odoo or in a customization, but there will always be the traceback of the exception, showing you where in the code the error is triggered. + +.. example:: + `odoo.exceptions.ValidationError: the tax group must have the same country_id as the tax using it.` + + We can find the source code that raises the issue by searching for the error message in the code base of Odoo which leads us to `this part of the code `_. With a little bit of technical knowledge, we can extrapolate that this error message will appear if there is one record of the `account.tax` model for which the country set on the tax group is different than the country set on the tax itself. + + With that in mind, we can now search in our database for the faulty taxes and fix them by setting their country to the country of their tax group (or the other way around). This can be done either manually via the web page of your database, or with PSQL queries or the Odoo shell, if you have access to those tools on your database. + +In regards to fixing the issue, we recommend that you first create a duplicate of your production database to test the fix on it, before applying the fix on your production database. Doing it this way ensures that you can catch any potential side effect of the fix. + +However, please note that sometimes the data in your production database does not trigger the issue, but some migration scripts in the upgrade process might create or modify records that would later down the line raise the exception and crash the upgrade process. In any case, you can always :doc:`request assistance ` that have the necessary tools to help you fix the issue. + +Upgrading server actions +------------------------ + +During an Upgrade, server actions can be problematic if they refer to fields that have been removed or renamed. They can either be entereliy removed from the database by the ORM or they can be kept but trigger an error when executed. + +Usually, only server actions for which the "Action To Do" is set to + +- Execute Python Code +- Create a new Record +- Update the Record + +can be problematic, since they would refer specific fields that can be changed with the upgrade. + +Thankfully though, fixing them is quite easy, since it only require you to fix the reference to the missing field. If your server action is still present on your upgraded database, you can do it manually but we recommend fixing it with a custom migration script. However, if your server action is removed by the standard upgrade process, you will have to take an action before submitting the upgrade request, or :doc:`request assistance ` from the Upgrade Team for more information. + +.. seealso:: + - :ref:`reference/actions/server` + - :doc:`/upgrade/advanced/migration_scripts` + +Upgrading Automated Actions +--------------------------- + +Automated actions can be upgraded in the same way as server actions, since they can both suffer from the same issues. + +This means that, just like server actions, when you upgrade your Odoo database you might encounter issues with the compatibility of your automated action, if the targeted model is changed or the field is not found anymore, etc . + +In case of deleted automated action +=================================== + +If your upgraded database does not contain your automated action anymore, this means that it has been deleted by the standard upgrade process, most likely due to the fact that the corresponding model has been removed by that process. In which case, you could either manually temporarily set the model of your automated action to a different one, just for upgrading, or you can request :doc:`request assistance ` of the Upgrade team to help you fix the issue. + +In case of error message when executed +====================================== + +Another other type of issue you can encounter with automated actions is an error message when they are triggered. For automated actions that execute Python code, this usually means that the Python code is not compatible with the upgraded version of your database, probably due to functions being renamed, fields being moved, etc. This means that you will have to upgrade the code, using the various tips and tricks written in :doc:`/upgrade/advanced/upgrade_custom_code`. + +.. seealso:: + :doc:`/applications/productivity/studio/automated_actions` \ No newline at end of file diff --git a/content/upgrade/advanced/upgrade_data/admin_access_rights.png b/content/upgrade/advanced/upgrade_data/admin_access_rights.png new file mode 100644 index 0000000000..77c7cc3e10 Binary files /dev/null and b/content/upgrade/advanced/upgrade_data/admin_access_rights.png differ diff --git a/content/upgrade/advanced/upgrade_process.rst b/content/upgrade/advanced/upgrade_process.rst new file mode 100644 index 0000000000..0d333793e3 --- /dev/null +++ b/content/upgrade/advanced/upgrade_process.rst @@ -0,0 +1,75 @@ +=================== +The upgrade process +=================== + +In this section, we will take a deeper look into the technical aspects that take place behind the scene when creating a request for an upgraded duplicated database. We will solely focus on the different steps that your data goes through, while the rest of the smartclass will focus on the aspects of the upgrade in general, from the planning to after the upgrade was applied in production. Even if some steps are done automatically, depending on what type of hosting you are on, we will still describe the process in depth just to give you a better understanding of what is happening behind the scenes. + + +.. image:: /upgrade/advanced/upgrade_process/schema_upgrade_process.png + :alt: Upgrade Process Schema + :align: center + +.. note:: + The upgrade process consists of all the actions that are taken on an Odoo database to create a copy of it in a later version of Odoo. It should not be confused with the processus of upgrading your Odoo database in which the upgrade process is one of the many steps, the other steps being the planning of the upgrade, the testing of the upgraded database, the day of the upgrade, etc ... + +.. important:: + During an upgrade, your database will be sent to a specific server managed by Odoo called the Upgrade Server where proprietary code will be executed on the database to upgrade it. This is why some steps consists of uploading/downloading data. + +Sending your database to the upgrade server +=========================================== + +The first step of any upgrade starts by converting the PSQL database, made of tables and records, into either a series of PSQL queries or an archive file. This process, called `dumping`, allows the rows and columns to be moved from one computer to another, in this case from the computer hosting the Odoo database to the Upgrade Server. This is usually done via the command `pg_dump` + +Then, the dump is sent to the Upgrade Server where it will be restored and upgraded. + +.. seealso:: + - `Documentation of pg_dump `_ + - `The Upgrade Server wepage `_ + - :doc:`/upgrade/request` + + +Upgrading the database on the upgrade server +============================================ +When the upgrade server receives your database in the file format, it will begin upgrading the data. First of all, the upgrade server will restore the database received from a file format to a PSQL database using a command such as `pg_restore`. + +Before any modifications are applied to the database received, a series of tests will be ran on the database to ensure the integrity and sanity of data and views. If any test fails, the upgrade process will stop. As there is no way to bypass any of those tests, your database will have to comply with them in order for the upgrade process to start. + +.. note:: + Those tests are extremely likely to succeed, as only a very wrong usage of Odoo will yield to one of those tests failing such as modifying the tables or columns of the database directly via PSQL in an unsupported way. + +Once all the tests have successfully been executed, the standard upgrade scripts will be ran. This part consists of thousands of migrations scripts being executed one after the other on the database, taking it through all the versions all the way to the targeted version. Those scripts are executed in an order related to their placement in folders and their file name. + +.. seealso:: + :doc:`Advanced : What are migration scripts ? ` + +It is possible that a Python exception is raised during the execution of those scripts, in which case you might have to fix the ill-formed data on your production database. Otherwise, if the issue is unrelated to the integrity of your data, you can ask the help of the Upgrade Support Analysts at Odoo (see :ref:`upgrade/test-assistance`) + +If all the migration scripts are ran successfully (i.e. no exception is raised) then the tests are ran again to make sure we don't want to return an ill-formed database. + +Once the database has passed all of the tests, the standard upgrade will be considered successful 🎉 If your database is running on an unmodified version of Odoo, then the process is complete and the upgraded database can be used as is. Otherwise, you will still have to go through upgrading the custom code and custom data. + +Receiving your upgraded database from the upgrade server +======================================================== + +.. tabs:: + + .. group-tab:: Odoo Online + + TODO find the exact steps to receive the database (access my-databases) + + .. group-tab:: Odoo SH + + By using the *Upgrade* tab (see :ref:`Odoo SH `), once the database is upgraded, it will automatically be restored on the branch you selected. Then, the custom scripts will be executed on the database to upgrade the custom code and custom data. Once this is successful, you will be able to test the upgraded database. + + .. group-tab:: On Premise + + TODO find the exact steps to receive the database (receive the DB via email ? ) + +In any case, now that the standard upgrade process is done, you will be able to receive the upgraded database that the upgrade server made. Depending on your hosting, the steps to receive it can differ but all of the details can be found in :doc:`/upgrade/request` + +Optional : executing custom upgrade scripts +=========================================== + +In the case that your database is running a modified version of Odoo, that is a version with custom modules or custom code, you will still have a little bit work more to do ! + +Since the various models and fields of Odoo might have changed during the upgrade of the database, you might have to adapt your customization to be compatible with it. Furthermore, if you do some changes to the structure of your custom code, you must not forget to migrate the data. For example if you rename a field in the code, you must also ensure that the corresponding PSQL data is renamed as well. This is usually done with :doc:`migration scripts ` by using PSQL queries or methods of the util package. \ No newline at end of file diff --git a/content/upgrade/advanced/upgrade_process/schema_upgrade_process.png b/content/upgrade/advanced/upgrade_process/schema_upgrade_process.png new file mode 100644 index 0000000000..29edc71b87 Binary files /dev/null and b/content/upgrade/advanced/upgrade_process/schema_upgrade_process.png differ diff --git a/content/upgrade/advanced/upgrade_studio.rst b/content/upgrade/advanced/upgrade_studio.rst new file mode 100644 index 0000000000..b714036825 --- /dev/null +++ b/content/upgrade/advanced/upgrade_studio.rst @@ -0,0 +1,127 @@ +=================================== +Upgrading your studio customization +=================================== + +Warning during the upgrade : The different types +------------------------------------------------ + +Unlike with data, the most common encounters you will have with Odoo studio in the logs will be warnings and not errors. The main difference between the two is that warnings will not block the upgrade process, meaning that it will be able to succeed and generate an upgraded database in which the problem displayed in the logs might still be present. + +Since the warnings are not blocking the upgrade process, we can fix the issues they are displaying in the custom part of the upgrade process. This means that the fix will be applied after the standard part of the upgrade process, and will be applied only if you are hosted on Odoo SH or On-Premise. For Odoo Online customers, you could either manually fix the issue after the upgrade using the web client, or :doc:`request assistance `. + +.. _upgrade_studio_views: + +Missing views customization and how to retrieve them +---------------------------------------------------- + +The most frequent and common issues raised by users during an upgrade is a significant difference in one or multiple views of their database. There are three reasons why a view can be different after an upgrade + +.. tabs:: + + .. group-tab:: A view you did not modify is different + + The change you notice is due to the change of the standard code of Odoo which is normal when upgrading to a new version. + + .. group-tab:: A view you modified with Odoo Studio is different + + If the source code of a standard view has changed, it may invalidate your custom view due to the nature of Odoo Studio customizations. In this case, you will have to adapt the code of your Odoo Studio view to match the new version view which is explained in :ref:`retargeting_the_xpath` + + .. group-tab:: A view you modified with a custom module is different + + This situation is covered in :ref:`Advanced : Upgrading your view inheritance `. + +In any case, the following warning will appear in the logs of your upgrade + +.. code-block:: + + The custom view `` (ID: , Inherit: , Model: ) caused validation issues. + Disabling it for the migration ... + +Where `` is the name of the view, `` is the id of the view in the database, `` is the id of the view it customizes, and `` is the model on which the view is defined, for example `sale.order`. It can also be accompanied by validation error itself, a Python error traceback that will allow you to see which xpath in the view caused the whole view to be invalid. + +.. example:: + .. code-block:: console + + 2023-09-04 15:04:33,686 28 INFO database odoo.addons.base.models.ir_ui_view: Element '' cannot be located in parent view + + View name: Odoo Studio: crm.lead.tree.opportunity customization + Error context: + view: ir.ui.view(1137,) + xmlid: studio_customization.odoo_studio_crm_lead_378fc723-a146-2f5b-b6a7-a2f7e15922f8 + view.model: crm.lead + view.parent: ir.ui.view(902,) + + 2023-09-04 15:04:34,315 28 WARNING db_1146520 odoo.addons.base.maintenance.migrations.base.pre-models-ir_ui_view: The custom view `Odoo Studio: crm.lead.tree.opportunity customization` (ID: 1137, Inherit: 902, Model: crm.lead) caused validation issues. + Disabling it for the migration ... + +This warning usually means that the target of one or more xpath are not found in the inherited view. This results in the view customization not being applied to the parent view, leading to missing customization or ill-formed views. It can be the case if the name of the targeted field has changed, or more likely if a new field was added above or below. For example, the xpath with target `//div[3]/group[2]/div[2]/field[1]` has many single points of failure possible given all the condition that the parent view must fulfill. + +If any of those elements are removed from the view, or moved to a different position, the target of the xpath has great chances of not being valid anymore. This is why we consider this kind of target for an xpath to be very fragile, as opposed to a target like `//field[@name='a_field_name']`` which can only break if the field is renamed, or if it is removed from the view. + +.. note:: + To minimize the chance of your Odoo studio views causing validation issues for this upgrade and in future upgrades, we recommend to preemptively rewrite the most fragile xpath in your views if you have the time or resources. It is not necessary for your upgrade to rewrite all of them, but it is a good thing to do to increase the health and resilience of your views. Moreover, fixing them preemptively in your database will ensure that you won't have to write a migration script to fix them after the upgrade, or :doc:`request assistance ` + +.. seealso:: + :ref:`reference/views` + :ref:`reference/views/inheritance` + +Finding the tag causing the issue +================================= + +Unarchiving the view in your database will trigger the validation error if the view is not valid and you will see the complete error message in the web client, allowing you to find the tag that is causing the issue. + +.. important:: + Successfully unarchiving a view does not always mean that the view is working properly, as the issue can hide in an invisible field or a field that the user does not have access to for example. In any case, navigating to the view and opening Odoo Studio will show you the validation error message in most cases. + +If the error message is not specific enough for you to find which tag is causing the issue, you can comment out half the xpath and save. If the error message is gone, the problematic tag is in the half you commented out. You can then repeat the process until you find the tag causing the issue. + +.. _retargeting_the_xpath: + +Retargeting the xpath +===================== + +Solving the validation issue is usually a matter of finding the right target for the xpath. The first step would be to find which XML tag in the parent view the xpath is targetting in your database, and then change the xpath to target the same XML tag in the upgraded database. + +You can make use of the function `edit_view` of util package TODO link util package to obtain the Etree element (from lxml library) by providing the xml_id of the view as parameter. Then you can use various method on those elments such as `xpath()`, `getparent()`, `remove()`, ... to apply your modifications. + +.. example:: + .. code-block:: python + + with util.edit_view(cr, "studio_customization.odoo_studio_project__e2f15f1a-2bdb-4003-a36e-ed72391a9fa2") as arch: + node = arch.xpath("""//xpath[@expr="//group[field[@name='activity_summary']]"]""")[0] + node.attrib["expr"] = "//field[@name='activity_summary']" + +Missing x_studio fields and how to retrieve them +------------------------------------------------ + +During the upgrade process, the migration scripts will ensure a certain synchronisation between the fields defined in the source code of your Odoo instance and the actual column names in the table of your PSQL database. In case of a mismatch, some actions can be taken on those columns, such as removing them. + +This happens frequently with fields created by Odoo Studio, which we call x_studio fields, on models that have been removed or fields that are related to such models. In those cases, the standard migration scripts will drop the table from the PSQL database after moving the standard data of the fields to the new table, *and not any custom field*. Thus the data of the x_studio fields will be lost. + +.. example:: + In the upgrade between Odoo 12 and Odoo 13, the model `account.invoice` was merged with `account.move` and was then subsequentely removed. The standard migrations scripts took care of moving the standard data from the PSQL table `account_invoice` to `account_move`, such as the columns `partner_id`, `name`, `amount_residual`, ... but any custom field created by the user will not be automatically moved. Then, once the migration of the data to `account_move` is completed, the table `account_invoice` is dropped, with all the custom data still in it. + +This is why we insist on thoroughly testing your upgraded database since any data loss will be unrecoverable once the upgrade of your production database is completed. + +Retrieving the fields +===================== + +Since the removal of your custom studio fields are executed by the standard migration scripts, you can not retrieve them by writing a custom migration script that is executed after the standard ones. Retrieving such fields is a manual process that can be done by the Upgrade team at Odoo. + +You can contact the Upgrade team by following the instructions in :doc:`/upgrade/assistance` and by specifying the following : +- The name of the field(s) removed from your database +- The name of the model(s) they were on +- The reason why they were removed (model removed, relation removed, related field removed, ...) +- Which new model, relation, or related field they should be on +- Any additional information that could help us retrieve the fields + +With that information, the Upgrade team will be able to save your field(s) by changing their definition before their deletion. This is usually done with PSQL queries or with methods from the util package TODO link util package at a very specific time during the standard upgrade process : between when the new model or the related field is created and when the old model or field is removed + +Upgrading your reports +---------------------- + +Fixing Studio report customisations is fortunately very similar to fixing Studio view customisations as both of them are based on the same xpath mechanis. The only difference being that the reports are built manually using ``, `
`, ``, ... elements, and therefore the xpath take action on those tags, instead of the usual ``, ``, ``, ... tags. + +By following the processes explained in :ref:`upgrade_studio_views` and :ref:`upgrade_views`, you should be able to fix your customization on reports in the same way you would fix your views. + +However, when dealing with entirely custom report, there is another situation that can arise. In Odoo, when duplicating a standard report, a copy of it is created at the time of the duplication with the same structure as the original. This means that once the source code of the original report is upgraded to match the new name of the various fields that were changed, the copy of the report will not be upgraded automatically. Thanfkully, this can be fixed quite easily by re-duplicating the original report, either with the Duplicate action, or by manually copying the source code from the original report to the copy. Then, you can apply the same process as explained in :ref:`upgrade_studio_views` and :ref:`upgrade_views` to fix the customization on the copied report. \ No newline at end of file diff --git a/content/upgrade/advanced/util_package.rst b/content/upgrade/advanced/util_package.rst new file mode 100644 index 0000000000..3d4b7afc6e --- /dev/null +++ b/content/upgrade/advanced/util_package.rst @@ -0,0 +1,9 @@ +==================== +The *"util"* package +==================== + +Using Odoo's web client makes it relatively straightforward to navigate from your dashboard to the specific interface necessary for your business operations. However, achieving the same level of precision through code can be more complex. In reality, to make modifications to records, whether they pertain to your business data or are related to elements within your Odoo database, such as views, fields, and so on, you may find yourself needing to write several dozen lines of code to ensure that your changes are applied precisely to the targeted data and trigger all the re-computation and updates needed. + +To simplify these tasks, we have recently released the *"util"* package alongside this documentation. This package contains a collection of valuable Python methods designed to perform high-level actions in a more generic and streamlined manner. With these methods, you can carry out various actions, including renaming a field in the database, relocating a field to another module, installing or upgrading a module, enforcing updates for "noupdate" data, recalculating fields, and more. + +To explore further details on utilizing the *"util"* package, please refer to the following [hyperlink]. diff --git a/content/upgrade/assistance.rst b/content/upgrade/assistance.rst new file mode 100644 index 0000000000..5264e45b30 --- /dev/null +++ b/content/upgrade/assistance.rst @@ -0,0 +1,54 @@ +.. |assistance-contact| replace:: + If you need Odoo assistance on this matter, please get in touch with your Odoo Account Manager or + our `Sales department`_. +.. _Sales department: mailto:sales@odoo.com + +========== +Assistance +========== + +.. _upgrade/test-assistance: + +Assistance with your test upgraded database +=========================================== + +If you encounter an issue in the **test database**, please get in touch with Odoo Upgrade Support +via the `Odoo Support page `_. + +Under the *Ticket type* section, select *An issue related to my future upgrade (I am testing an upgrade)* ticket type. + + .. image:: ../upgrade/assistance/test-assistance.png + :width: 50% + :align: center + :alt: Selection of "An issue related to my future upgrade (I am testing an upgrade)" as Ticket Type in the support form on Odoo + + .. warning:: + If you choose another *Ticket type*, the request will be redirected to another team. This will slow down the processing and response time. + +Please provide as much detail as you can (i.e., videos and screenshots to illustrate your issue). +This will avoid clarifying questions and speed up the resolution process significantly. + +.. note:: + * The purpose of the test phase is not to correct existing data or configurations in your database. + * |assistance-contact| + +.. _upgrade/production-assistance: + +Assistance with your upgraded production database +================================================= + + +If you encounter issues or problems in the **production database**, please get in touch with **Odoo +Support**: + +#. Connect to our `Odoo Support page `_. +#. Under the *Ticket Description* section, select the appropriate type related to your issue : *An issue related to my future upgrade (production)* + + .. note:: + After upgrading to production, the support will be provided by the Support team instead of the Upgrade team. + +#. Please provide as much detail as you can (i.e., videos and screenshots to illustrate your issue). This will avoid clarifying questions and speed up the resolution process significantly. + + .. warning:: + If you choose *An issue related to my upgrade* as ticket type, the request will be redirected to another team than the support one and will slow down the processing and response time. + diff --git a/content/upgrade/assistance/test-assistance.png b/content/upgrade/assistance/test-assistance.png new file mode 100644 index 0000000000..e036c77901 Binary files /dev/null and b/content/upgrade/assistance/test-assistance.png differ diff --git a/content/administration/upgrade/test-purpose.png b/content/upgrade/assistance/test-purpose.png similarity index 100% rename from content/administration/upgrade/test-purpose.png rename to content/upgrade/assistance/test-purpose.png diff --git a/content/administration/upgrade/faq.rst b/content/upgrade/faq.rst similarity index 64% rename from content/administration/upgrade/faq.rst rename to content/upgrade/faq.rst index f4fba7a735..3a831a309c 100644 --- a/content/administration/upgrade/faq.rst +++ b/content/upgrade/faq.rst @@ -1,34 +1,25 @@ .. |assistance-contact| replace:: - If you need Odoo assistance on this matter, please get in touch with your Odoo Account Manager or - our `Sales department`_. + If you need Odoo assistance on this matter, please get in touch with your Odoo Account Manager or our `Sales department`_. .. _Sales department: mailto:sales@odoo.com === FAQ === -.. _upgrade-faq/why: - -Why upgrade -=========== - -* You benefit from the latest features of the :ref:`new major version - ` released by Odoo. -* If you are in an :ref:`unsupported version `, you get a new version - with support. +TODO merge FAQ into sections .. _upgrade-faq/when: -When to upgrade -=============== +When should I upgrade ? +======================= Whenever you want. You can make your upgrade request as soon as a new version is released or when your version turns unsupported, and you still wish to enjoy support. .. _upgrade-faq/availability: -Availability of the new version -=============================== +When can I upgrade to a the newly released version? +=================================================== As soon as Odoo announces the release of a new major version, you can create a test upgrade request to try the latest version. Please note that at this point, the upgrade scripts will only have been @@ -38,52 +29,50 @@ requesting the upgrade of your database in production. .. _upgrade-faq/duration: -Duration of the upgrade -======================= +How long does it take to upgrade my database? +============================================= + +It is impossible to give time estimates for every upgrade request. However, it is heavily correlated to the size of the database, the number of installed apps, and the amount of users. The more data you have, the longer it will take to upgrade. + +For example, a single-user database that only uses CRM will be processed faster than a multi-company, multi-user database that uses Accounting, Sales, Purchase, and Manufacturing. -It is impossible to give time estimates for every upgrade request. +In a nutshell, the lead time of your upgrade can be impacted by the following aspects: -In general, the "smaller" the database, the quickest the upgrade request is completed. A single-user -database that uses only CRM will be processed faster than a multi-company, multi-user database that -uses Accounting, Sales, Purchase, and Manufacturing. +* Source & targeted versions +* Installed apps +* Volume of data +* Amount of customization (models, fields, methods, workflows, reports, website, etc.) +* Installation of new apps or configuration changes after the start of the test phase +* Users and database administrator commitment You can expect the time it takes for the platform to upgrade the test database to be similar to the production upgrade. .. _upgrade-faq/project: -Duration of the upgrade project -------------------------------- +What is the time frame for an upgrade project? +---------------------------------------------- It depends on the user involvement (the time spent on testing, reporting problems, etc.) and the issues encountered that might need to be addressed by our technical team. -So, in a nutshell, what can impact your upgrade lead time? - -* Source & targeted versions -* Installed apps -* Volume of data -* Amount of customization (models, fields, methods, workflows, reports, website, etc.) -* Installation of new apps or configuration changes after the start of the test phase -* User commitment - .. _upgrade-faq/custom-modules: -Upgrade of the custom modules -============================= +Who will I upgrade my custom modules? +===================================== + +The responsible for the maintenance of your custom modules should be responsible for the upgrade of your custom modules. If you have a contract with Odoo for the maintenance of your custom modules as stated in our :doc:`/legal/terms/enterprise`, section :ref:`charges_standard`, we will upgrade your custom modules as covered by your contract. -As stated in our :doc:`/legal/terms/enterprise`, section :ref:`charges_standard`, this optional -service is subject to additional fees. +If you do not have a contract with Odoo for the maintenance of your custom modules, you can either upgrade them yourself or ask Odoo to do it for you. In this case, you will be charged for the time spent by our developers to upgrade your custom modules. -Depending on your situation, the custom code could be upgraded by our services, by one of our -partners, or you can do it yourself. +Finally, if an Odoo partner developed your custom modules, you should contact them to upgrade your custom modules. .. note:: |assistance-contact| .. _upgrade-faq/upgrade-or-migration: -Upgrade or Migration -==================== +What is the difference between an upgrade and a migration? +========================================================== An upgrade is switching to a newer version of Odoo, while a migration reflects the change of :ref:`editions ` or change of :ref:`hosting type @@ -93,52 +82,45 @@ An upgrade is switching to a newer version of Odoo, while a migration reflects t .. _upgrade-faq/editions-change: -Editions change (from Community to Enterprise) -============================================== +Why do I get an Enterprise edition after my upgrade? +==================================================== -The upgrade always returns an Enterprise edition of Odoo, whether the database you sent was a -community or enterprise edition. It is required to have an enterprise subscription to upgrade. +The upgrade always returns an Enterprise edition of Odoo, whether the database you sent was a community or enterprise edition since it is required to have an enterprise subscription to upgrade. - .. note:: - If you need assistance on this matter, please contact us via the `Odoo Support page - `_. +.. note:: + If you need assistance on this matter, please contact us via the `Odoo Support page `_. .. seealso:: - `Editions `_ .. _upgrade-faq/hosting-types-switch: -Switching the hosting types (On-premise vs. Odoo Online vs. Odoo.sh) -==================================================================== +How can I change my hosting type (On-premise vs. Odoo Online vs. Odoo.sh) ? +=========================================================================== An upgrade does not cover a change of `Hosting types `_. -Open the following link to get :doc:`more information about how to change your hosting type -<../maintain/hosting_changes>`. +You can find more information about how to change your hosting type :doc:`here `. .. note:: |assistance-contact| .. _upgrade-faq/upgrade-report: -The Upgrade Report -================== +What is an upgrade report ? +=========================== When an upgrade request completes successfully (test or production), you receive an email -notification about it that includes an 'Upgrade Report'. This report is also sent to you via the -Discuss app. It contains valuable information regarding changes that occurred during the upgrade. -While it serves as a guide to possible issues to look out for, it is not an exhaustive list. It -remains imperative that you test the upgraded database thoroughly and report any discrepancies you -might find, before you decide to upgrade your production database. +notification about it that includes an 'Upgrade Report'. It contains valuable information regarding changes that occurred during the upgrade. While it serves as a guide to possible issues to look out for, it is not an exhaustive list. It remains imperative that you :ref:`test ` the upgraded database thoroughly and report any discrepancies you might find, before you decide to upgrade your production database. + +..note:: + The upgrade report is sent to you via email after an upgrade request successfully completes (test or production), and is also available in the Discuss app of your database. .. _upgrade-faq/custom-views: -Custom views -============ +Why are there issues with my custom views after the upgrade? +============================================================ -During the upgrade, some custom views might get disabled for technical reasons. Therefore they might -have to be fixed after the upgrade. The :ref:`Upgrade Report ` that is -generated after the upgrade is available in the Discuss app, and lists all the custom views that -might be impacted by this. +During the upgrade, some custom views might get disabled for technical reasons. Therefore they might have to be fixed after the upgrade. The :ref:`Upgrade Report ` that is generated after the upgrade lists all the custom views that might be impacted by this. You can find more information about how to fix custom views :ref:`here ` and how to fix studio views :ref:`here `. .. _upgrade-faq/release-notes: @@ -204,6 +186,8 @@ are permanently deleted following that period. You can learn more about privacy and data handling at Odoo by visiting our `General Data Protection Regulation page `_. +.. _upgrade_faq/rolling_release: + Rolling Release (applicable to Odoo Online databases) ===================================================== diff --git a/content/upgrade/introduction.rst b/content/upgrade/introduction.rst new file mode 100644 index 0000000000..78e422b2af --- /dev/null +++ b/content/upgrade/introduction.rst @@ -0,0 +1,191 @@ +:nosearch: +:show-toc: + + +.. |assistance-contact| replace:: + If you need Odoo assistance on this matter, please get in touch with your Odoo Account Manager or + our `Sales department`_. +.. _Sales department: mailto:sales@odoo.com + +=============== +Getting started +=============== + +Introduction to upgrades +------------------------ + +In Odoo, an upgrade is the process of moving your database from an older version of Odoo to a newer, supported version. Each new version of Odoo comes with new features, bug fixes, security patches, and improvements. Depending on your hosting type and the size of the database, the upgrade process can be very straightforward and be done automatically, or require some assistance from our Upgrade department. + +Here are a few examples of supported upgrades: + +* Odoo 11 to Odoo 15 +* Odoo 14 to Odoo 16 +* Odoo 13 to Odoo 15 + +.. important:: + An upgrade does not cover + + * Downgrading to a previous version of Odoo (i.e., Odoo 15 to Odoo 12) + * Changing :ref:`editions ` (i.e., Community to Enterprise edition) + * Switching :ref:`hosting type ` (i.e., On-Premise to Odoo Online or Odoo.sh) + * Migration from another ERP to Odoo + +.. note:: |assistance-contact| + +Importance of regular upgrades +------------------------------ + +It is important to keep your database up-to-date for several reasons: + +* Benefiting from the latest features of the :ref:`new major version ` released by Odoo. +* Only :doc:`supported versions ` of Odoo receive security patches and bug fixes. +* Benefiting from the latest performance improvements. + +Please note that Odoo provides support and bug fixing only for the three last major versions of Odoo. + +This is a factor to take into consideration before upgrading. If you are on an older version, we suggest you to prefer the most recent version to benefit from longer support (before having to upgrade again). + +.. _upgrade/process-workflow: + +Overview of the upgrade project +--------------------------------------------- + +An upgrade project represents the whole procedure of upgrading an Odoo database, +from the decision of the upgrade, all the way to having the database running the upgraded version. + +Planning the upgrade +==================== + +The first step of this journey is obviously the planning. You will have to allocate some time and resources for building the planning of your upgrade, whether you are doing it by yourself or with the help of a business analyst or an upgrade support analyst here at Odoo. + +Depending on the size of your database, the amount of apps installed, the amount of customization, and the availability of the Upgrade team, the time span of the upgrade can vary a lot but we usually consider between 1 and 3 month for the average database. However, please note that this estimate can very a lot based on those factors. Some very specific upgrades can take up to 6 months to be completed but that is very rare. + +.. important:: + Since upgrading can bring a lot of changes to the business flow, you should also plan for a significant amount of time in testing before the upgrade of your production database. This will allow you to catch all of the possible bugs and issues that could have appeared during the upgrade, as well as to get familiar with latest changes that the new version brings. It is more convenient to discover problems during the testing phase than to have to deal with an issue when operating your database in the middle of a busy day. + + +Submitting your first request +============================= + +Once you finished planning the upgrade, the next step is to request your first upgraded test database by following the instructions in the corresponding section of this documentation: + + - :doc:`Upgrade request for Odoo Online <../upgrade/request/odoo_online>` + - :doc:`Upgrade request for Odoo.sh <../upgrade/request/odoo_sh>` + - :doc:`Upgrade request for On-Premise <../upgrade/request/on_premise>` + +You will then be notified of the status of your request. Once your request has been successfully process, you will be given instructions on how to access your test database. Otherwise, you might have to fix a few things in your database or contact the upgrade support of Odoo for help you with your blocked upgrade request. You can find more information in regards to the assistance Odoo provides in :ref:`upgrade/test-assistance`. + +In any case, you can always request another upgraded test database at any time. It can be useful in case you significantly changed your test database or if a fix was applied to the upgrade process and you need to confirm that it is working as expected. + +.. _upgrade/testing-phase: + +Assessing your upgraded database and requesting help +==================================================== + +Once you receive your test database, it is very important to spend a significant amount of time assessing it to ensure that, once the upgrade goes live, you are not stuck in your day-to-day activities by a change in views, behavior, or an error message. + +.. admonition:: A few things you should check + + - Are there views that are deactivated in your test database but active in your production database ? + - Are your usual views still displayed correctly ? + - Are your reports (Invoice, Sales Order, etc.) correctly generated ? + - Are your website pages working correctly ? + - Are you able to create and modify records ? (Sales order, invoices, purchases, users, contacts, companies, etc ... ) + +Also, we strongly recommend to test your business flow end-to-end. This means that you should test the whole process of your business, from the creation of a sales order to the payment of the invoice for example. This will allow you to catch any issue that could have appeared during the upgrade and as an added bonus, you will get familiar with the new version of Odoo. + +Examples of end-to-end testing : + - Check a random product in your product catalog and compare its test and production data (product category, selling price, cost price, is the vendor set? Are the same accounts set ? Are the same Routes set?); + - Buy this product (only available with Purchase App); + - Confirm the reception of this product (only available with Inventory App); + - Check if the route to receipt this product applies the same set in your production database (only available with Inventory App); + - Sell this product (only available with Sales App) to a random customer; + - Open your customer database (Contact App), select a random customer (or company) and double-check its data; + - Ship this product (only available with Inventory App); + - Check if the route to ship this product applies the same set in your production database (only available with Inventory App); + - Validate a customer invoice (only available with Invoicing and/or Accounting Apps); + - Credit the invoice (issue a credit note) and check if its behaves as your production database; + - Check your Reports results (only available with Accounting Apps); + - Randomly check your taxes, currencies, Bank Account. Is your fiscal year set in production database the same? (only available with Accounting Apps); + - Proceed to an online order (only available with Website Apps) from the product selection in your shop until the checkout process and check if its behaves as your production database. + +Depending on the complexity of your database, you also shouldn't forget to test : + - Integrations with external softwares (EDI, APIs, ...) + - Workflows between different Apps (online sales with eCommerce, converting a lead all the way to a sales order, delivery of products, etc ... ) + - Exporting data + - Your automated actions to make sure they work + - Your server actions in the Action menu on form views as well as by selecting multiple records on list views + +Those are non-exhaustive lists that you can extend to your other Apps based on your use of Odoo. + +You should :ref:`report any issue ` you encounter during your testing phase to the Odoo Upgrade Support. + +.. important:: + A test database is only intended for testing and remains completely unrelated to your present or future production database. Any data you add, or changes you make, will not be reflected in your upgraded production database. + +.. note:: + Test databases are neutered and features are disabled to prevent them from having an impact on the production database: + + #. Scheduled actions are disabled. + #. Outgoing mail servers are disabled by archiving the existing ones and adding a fake/non-working one. + #. Payment providers and delivery carriers are reset to test environment. + + + +Upgrading your customizations +============================== + +In the case that your database is running a modified version of Odoo, that is a version with custom modules or custom code, you will still have a little bit work more to do ! + +Since the various models and fields of Odoo might have changed during the upgrade of the database, you might have to adapt your customization to be compatible with it. Furthermore, if you do some changes to the structure of your custom code, you must not forget to migrate the data. For example if you rename a field in the code, you must also ensure that the corresponding PSQL data is renamed as well. This is usually done in :doc:`/upgrade/advanced/migration_scripts`. + +.. _upgrade/steps-production: + +Upgrading your production database +================================== + +Once you completed your :ref:`tests ` and are confident that you can use your upgraded database as your main database without any issue, it is time to plan the Go-live day. During the upgrade of your production database, any modification done on it will not be saved. This is why we recommend not using your database during that time. + +.. important:: + Going into production without first testing may lead to: + + - business interruptions (e.g., no longer having the possibility to validate an action) + - poor customer experiences (e.g., an eCommerce website that does not work correctly) + + +After the upgrade +================= + +Once your production database is running the upgraded version, you can continue using it as your main Odoo database as usual. If you encounter any new issue, you can still request :ref:`upgrade/production-assistance` + + +Factors influencing the complexity of the upgrade +------------------------------------------------- + +For most databases, the upgrade process is actually very straightforward and can be done by the database administrator at any time (see :doc:`/upgrade/request`). However, for more complex databases such as those with a lot of custom modules or a lot of data, the upgrade should be executed in collaboration with a developer. This is because with each changes in the standard of Odoo, any customization (Modified reports, web pages, custom views, custom code, ... ) might be impacted by the upgrade and could potentially not work anymore. + +Let's view an example by comparing screenshots from different two different versions of Odoo : Odoo 14 and Odoo 16. + +.. image:: introduction/so_odoo_14.png + :width: 49% + :alt: Odoo 14 + +.. image:: introduction/so_odoo_16.png + :width: 49% + :alt: Odoo 16 + +Apart from the fonts used and the spacing between fields, we notice a few things : + +- Field 'Referrer' moved from below 'Quotation template' to below 'Customer' +- A new field named 'Recurrence' appears on the right, below 'Order Date' + + +Those changes might not be important to end user but for programmers developing a module, the code written is often based on the current layout of the pages, and on the current fields present. Therefore if a new field was created and placed under the field 'Referrer', since 'Referrer' changed position, our new field would followed it. + +.. important:: + Changes between versions of the standard code of Odoo could impact the dependencies of your custom modules and therefore require some changes to your code. + +Now, this example highlight a very minor change, as nothing is deleted, but this is not always the case between 2 versions. Sometimes, fields are renamed or removed entirely from the database, whole modules are changed, models are renamed, etc ... Thankfully the standard code of Odoo is written in a way that it will automatically move the standard data from the old field to the new one, but this is not the case for customized fields. + +In those situations, running the newest version of Odoo on an older database will probably result in issues when navigating your database, such as error messages, data loss, data showing incorrectly, values wrongly computed, and many more. Therefore, the intervention of a developer will be required for your upgrade to be successful. + diff --git a/content/upgrade/introduction/so_odoo_14.png b/content/upgrade/introduction/so_odoo_14.png new file mode 100644 index 0000000000..3252231c2b Binary files /dev/null and b/content/upgrade/introduction/so_odoo_14.png differ diff --git a/content/upgrade/introduction/so_odoo_16.png b/content/upgrade/introduction/so_odoo_16.png new file mode 100644 index 0000000000..3252231c2b Binary files /dev/null and b/content/upgrade/introduction/so_odoo_16.png differ diff --git a/content/upgrade/preparing.rst b/content/upgrade/preparing.rst new file mode 100644 index 0000000000..7e6c5c7835 --- /dev/null +++ b/content/upgrade/preparing.rst @@ -0,0 +1,58 @@ +:nosearch: +:show-toc: + +===================== +Planning your upgrade +===================== + +Which version should you target ? +--------------------------------- + +As you may know, Odoo :doc:`supports only certain versions `. This means that running any unsupported version of Odoo exposes your database to potential security issues, bugs and performance issues that will not be fixed by Odoo. This is the reason why we invite our user to stay up-to-date with the latest versions. + +.. - Odoo Online, the hosting you get by default when creating your database via our website (Also known as Saas) +.. - Odoo SH, the cloud platform specifically designed to host and customize Odoo databases +.. - On-premise : this refers to all databases that are fully administered by the user, whether it is hosted on another cloud platform, on a server on-site, on a computer, etc ... + +To make it simple, our recommendation is to upgrade to the latest major version of Odoo, that is the version released every year around the Odoo experience. Depending on you hosting, the reason for this recommendation might be different. + +.. tabs:: + + .. group-tab:: Odoo Online + + Odoo Online databases are usually automatically upgraded through all of the minor and major versions of Odoo at each new release thanks to the :ref:`upgrade_faq/rolling_release` mechanism. If the rolling release is unable to upgrade your database, it is recommended to upgrade it to the latest major version of Odoo. + + .. group-tab:: Odoo SH + + There are 3 possible situations with Odoo hosted on Odoo SH : + + - You are in charge of your own code and you use Odoo SH to manage and run it. + - You delegated the responsibility of developing and maintaining the code of your customizations to the Service department of Odoo. + - The development and maintenance of your code hosted on Odoo SH is handled by a third party (such as an Odoo partner) + + Since upgrading can be a time consuming process, it is recommended to upgrade to the latest version of Odoo to minimize the amount of upgrades you will have to go through in the lifetime of your database. Unlike on premise where you are in charge of the hardware and operating system, with Odoo SH it is always Odoo that takes care of that, regardless of the situation that you are in. This is why it is not possible to run :doc:`Unsupported versions ` on Odoo SH. + + .. note:: + Minor versions of Odoo (for example Odoo 16.4) that are released multiple times a year are only available to Odoo Online databases. + + + .. group-tab:: On-Premise + + On-Premise database administrators are in charge of their own hardware and operating system, which means that they can run any version of Odoo they want. However, since Odoo only provides support for the 3 latest versions, it is recommended to upgrade to one of those versions to ensure that you will be able to get support from Odoo if you ever need it. + + To minimize the amount of upgrades you will have to go through in the lifetime of your database, it is recommended to upgrade to the latest version of Odoo. + + .. note:: + Minor versions of Odoo (for example Odoo 16.4) that are released multiple times a year are only available to Odoo Online databases. + + +.. important:: + Running an :doc:`unsupported version ` of Odoo is discouraged as it will prevent you from getting new security updates, performance improvements and bug fixes. Odoo support will also not be able to help you with any issue you encounter in that version. + + +Are your customizations still necessary ? +----------------------------------------- + +During an upgrade, especially given the fact that you might skip multiple versions of Odoo, it is very likely that, in the plethora of new features added in the years of development between 2 versions, what you added in your database as a customization might be part of the standard of Odoo now. + +This is why we recommend every database manager to take the time to explore the new features of Odoo and to compare them with the current customizations implemented. With a little bit of luck, you might be able to delete some chunks of your customization, leading to less time and money spent on its maintenance. diff --git a/content/upgrade/request.rst b/content/upgrade/request.rst new file mode 100644 index 0000000000..d185c813f3 --- /dev/null +++ b/content/upgrade/request.rst @@ -0,0 +1,12 @@ +:nosearch: +:show-toc: + +============================== +Request your upgraded database +============================== + +.. toctree:: + + request/odoo_online + request/odoo_sh + request/on_premise diff --git a/content/administration/upgrade/odoo_online.rst b/content/upgrade/request/odoo_online.rst similarity index 100% rename from content/administration/upgrade/odoo_online.rst rename to content/upgrade/request/odoo_online.rst diff --git a/content/administration/upgrade/odoo_online/database-notification.png b/content/upgrade/request/odoo_online/database-notification.png similarity index 100% rename from content/administration/upgrade/odoo_online/database-notification.png rename to content/upgrade/request/odoo_online/database-notification.png diff --git a/content/administration/upgrade/odoo_online/databases-page.png b/content/upgrade/request/odoo_online/databases-page.png similarity index 100% rename from content/administration/upgrade/odoo_online/databases-page.png rename to content/upgrade/request/odoo_online/databases-page.png diff --git a/content/administration/upgrade/odoo_online/test-database.png b/content/upgrade/request/odoo_online/test-database.png similarity index 100% rename from content/administration/upgrade/odoo_online/test-database.png rename to content/upgrade/request/odoo_online/test-database.png diff --git a/content/administration/upgrade/odoo_online/upgrade-in-progress.png b/content/upgrade/request/odoo_online/upgrade-in-progress.png similarity index 100% rename from content/administration/upgrade/odoo_online/upgrade-in-progress.png rename to content/upgrade/request/odoo_online/upgrade-in-progress.png diff --git a/content/administration/upgrade/odoo_online/upgrade-pop-up.png b/content/upgrade/request/odoo_online/upgrade-pop-up.png similarity index 100% rename from content/administration/upgrade/odoo_online/upgrade-pop-up.png rename to content/upgrade/request/odoo_online/upgrade-pop-up.png diff --git a/content/administration/upgrade/odoo_sh.rst b/content/upgrade/request/odoo_sh.rst similarity index 95% rename from content/administration/upgrade/odoo_sh.rst rename to content/upgrade/request/odoo_sh.rst index b1d63c3dd0..0df9270d8a 100644 --- a/content/administration/upgrade/odoo_sh.rst +++ b/content/upgrade/request/odoo_sh.rst @@ -2,7 +2,7 @@ Odoo.sh ======= -.. _upgrade/odoo_sh/overview: +.. _upgrade/request/odoo_sh/overview: Overview ======== @@ -26,11 +26,11 @@ The suggested upgrade steps on Odoo.sh are: #. Trigger the production upgrade from your :guilabel:`Production` branch and sit tight. .. seealso:: - - :doc:`../../administration/upgrade` - - :doc:`Upgrade FAQ <../upgrade/faq>` - - :doc:`Introduction to Odoo.sh <../odoo_sh/overview/introduction>` + - :doc:`/upgrade` + - :doc:`Upgrade FAQ <../faq>` + - :doc:`Introduction to Odoo.sh <../../administration/odoo_sh/overview/introduction>` -.. _upgrade/odoo_sh/custom-modules: +.. _upgrade/request/odoo_sh/custom-modules: Upgrade your custom modules =========================== @@ -45,7 +45,7 @@ correctly. Depending on your contract, the upgrade of your custom modules can be done by yourself, by your Partner or by Odoo (if you hold a subscription including maintenance of customizations). -.. _upgrade/odoo_sh/testing-phase: +.. _upgrade/request/odoo_sh/testing-phase: Upgrade your database on a staging branch ========================================= diff --git a/content/administration/upgrade/odoo_sh/odoo-sh-menu.png b/content/upgrade/request/odoo_sh/odoo-sh-menu.png similarity index 100% rename from content/administration/upgrade/odoo_sh/odoo-sh-menu.png rename to content/upgrade/request/odoo_sh/odoo-sh-menu.png diff --git a/content/administration/upgrade/odoo_sh/odoo-sh-prod.png b/content/upgrade/request/odoo_sh/odoo-sh-prod.png similarity index 100% rename from content/administration/upgrade/odoo_sh/odoo-sh-prod.png rename to content/upgrade/request/odoo_sh/odoo-sh-prod.png diff --git a/content/administration/upgrade/odoo_sh/odoo-sh-progress.png b/content/upgrade/request/odoo_sh/odoo-sh-progress.png similarity index 100% rename from content/administration/upgrade/odoo_sh/odoo-sh-progress.png rename to content/upgrade/request/odoo_sh/odoo-sh-progress.png diff --git a/content/administration/upgrade/odoo_sh/odoo-sh-staging.png b/content/upgrade/request/odoo_sh/odoo-sh-staging.png similarity index 100% rename from content/administration/upgrade/odoo_sh/odoo-sh-staging.png rename to content/upgrade/request/odoo_sh/odoo-sh-staging.png diff --git a/content/administration/upgrade/on_premise.rst b/content/upgrade/request/on_premise.rst similarity index 100% rename from content/administration/upgrade/on_premise.rst rename to content/upgrade/request/on_premise.rst diff --git a/content/upgrade/sla.rst b/content/upgrade/sla.rst new file mode 100644 index 0000000000..0277f19a20 --- /dev/null +++ b/content/upgrade/sla.rst @@ -0,0 +1,46 @@ +.. |assistance-contact| replace:: + If you need Odoo assistance on this matter, please get in touch with your Odoo Account Manager or + our `Sales department`_. +.. _Sales department: mailto:sales@odoo.com + +============================= +Service-level agreement (SLA) +============================= + +With Odoo Enterprise, upgrading a database to the most recent version of Odoo is **free**, including +any support required to rectify potential discrepancies in the upgraded database. + +Information about the upgrade services included in the Enterprise Licence is available in the +:ref:`Odoo Enterprise Subscription Agreement `. However, this section clarifies what +upgrade services you can expect. + +Upgrade services covered by the SLA +----------------------------------- + +Databases hosted on Odoo's cloud platforms (Odoo Online and Odoo.sh) or self-hosted (On-Premise) can +benefit from upgrade services at all times for: + +- the upgrade of all **standard applications**; +- the upgrade of all **customizations created with the Studio app**, as long as Studio is still installed and the respective subscription is still active; and +- the upgrade of all **developments and customizations covered by a maintenance of customizations subscription**. + +Upgrade services are limited to the technical conversion and adaptation of a database (standard +modules and data) to make it compatible with the version targeted by the upgrade. + +Upgrade services not covered by the SLA +--------------------------------------- + +The following upgrade-related services are **not** included: + +- the **cleaning** of pre-existing data and configurations while upgrading; +- the upgrade of **custom modules created in-house or by third parties**, including Odoo partners; +- lines of **code added to standard modules**, i.e., customizations created outside the Studio app, code entered manually, and :ref:`automated actions using Python code `; and +- **training** on using the upgraded version's features and workflows. + +.. note:: |assistance-contact| + +.. seealso:: + - :doc:`Upgrade FAQ ` + - :doc:`Odoo.sh documentation ` + - :doc:`Supported Odoo versions ` +