Skip to content

Migration to 12.0

Jump to bottom
Iván Todorovich edited this page Jan 24, 2020 · 13 revisions

12.0 is an orphan branch, meaning that it's not continuing the history of 9.0. We'll start from scratch to keep it clean.

We don't want to migrate all the modules, but for the modules we do migrate, we want to keep the original commit history and authors.

To do this we use the OCA approach. We'll do something similar to what's described here: https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-12.0

Technical method to migrate a module from "9.0" to "12.0" branch

  • $MODULEDIR: the module folder on 9.0 branch (ie: intercoop_addons)
  • $MODULE: the name of the module you want to migrate

So, first we'll copy the commit history from the 9.0 branch to 12.0

  1. Clone repository (if you haven't already, this step can be avoided)
$ git clone git@github.com:druidoo/FoodCoops.git
$ cd FoodCoops
  1. Update local 9.0 branch to match dev branch at AwesomeFoodcoops (do it always before migrating a module)
$ git remote add foodcoops git@github.com:AwesomeFoodCoops/odoo-production.git
$ git fetch foodcoops
$ git checkout 9.0
$ git reset --hard foodcoops/dev
  1. Create branch for the migration of our module
$ git checkout -b 12.0-mig-$MODULE origin/12.0
  1. Copy commit history of this module in our new branch
$ git format-patch --keep-subject --stdout origin/12.0..origin/9.0 -- $MODULEDIR/$MODULE | git am -3 --keep

Troubleshooting

If there are conflicts when applying the patches, most of the times we want to prioritize them by order.. giving more priority to the more recent commit. We want to keep the commit history, but we don't want to spend much time on it.

Sometimes, when performing these operations, the process can hang due to conflicts on the patches being applied. One of the possible problems is because a patch removes entirely a file and git am is not able to resolve this. It ends with a message error: ...: patch does not apply.

If that's your case, you can add --ignore-whitespace at the end of the git am command for allowing the patch to be applied, although there will be still conflicts to be solved, but they will be doable through standard conflict resolution system. Starting from the previous situation, you will need to do:

git am --abort
git format-patch --keep-subject --stdout origin/12.0..origin/9.0 -- <module path> | git am -3 --keep --ignore-whitespace
# resolve conflicts (for example git rm <file>)
git add --all
git am --continue

Code migration

After we have the module with all the commit history in our new branch, make the appropiate changes like moving the module from coop_addons/ to the root directory

git mv coop_addons/<module> <module>

And the actual migration commits. Use this format as the commit message: [MIG] Migration to 12.0: <module name>

Checklist

You can use this task list as guide on things we need to keep an eye for during the migration:

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-10.0#tasks-to-do-in-the-migration https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-11.0#tasks-to-do-in-the-migration https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-12.0#tasks-to-do-in-the-migration

Not every task applies in our case, but it might be good for you to read it. Here's a list of things taken from those lists that apply for this project:

  • Bump module version to 12.0.1.0.0

  • Make sure the manifest contains proper copyrights, licence and author information. Do not remove previous copyrights, but make sure Druidoo is there. And that it's cleanly structured:

# Copyright (C) 2019-Today: La Louve (<https://cooplalouve.fr>)
# Copyright (C) 2019-Today: Druidoo (<https://www.druidoo.io>)
# License AGPL-3.0 or later (http://www.gnu.org/licenses/agpl.html).
{
   'name': 'Point of Sale - Session Summary',
   'version': '12.0.1.0.0',
   'category': 'Point Of Sale',
   'summary': 'Point of Sale - Total of transactions and Orders Quantity',
   'author': 'Druidoo',
   'website': 'https://cooplalouve.fr/',
   'depends': [
       'base',
   ],
   'data': [
   ],
   'license': 'AGPL-3',

  • Remove any possible migration script from previous version (located in folder migration, we probably don't have any)

  • The first line # -*- coding: utf-8 -*- is not needed anymore in Python 3 if you save it in that encoding. You can use the following command to auto-delete it:

find . -name "*.py" -exec sed -i "/#.*coding\: /d" {} \;

  • Convert Python 3 incompatible code. You can automate some things using 2to3 utility (bundled in most Linux distributions) with this command being on the module directory (it can require a later manual review for optimizing some sentences):

2to3 -wnj4 --no-diffs .

You can also check Python 3 compatibility and conversions guide by Odoo: https://github.com/odoo/odoo/blob/11.0/doc/python3.rst

  • Migrate code to new ORM API if not yet.

  • Replace openerp imports to odoo. You can use this command:

find . -type f -name '*.py' | xargs sed -i 's/from openerp/from odoo/g'

  • Rename __openerp__.py to __manifest__.py if not yet renamed.

  • Replace select = True by index = True on field definitions.

  • Replace string selectors in XML by name (if possible) or other attribute selector or even another equivalent path/reference. For example, change <group string="x" position="after"> by <group name="x" position="after">

  • Remove <data> and </data> in xml files if there isn't an explicit noupdate="1"

  • Replace the <openerp>/</openerp> tags in xml files by <odoo>/</odoo>.

  • Remove @api.one. It's been deprecated. Replace it with an implicit @api.multi and for rec in self:.

  • Change decorator of copy method def copy(self): from @api.one to @api.multi.

  • base.group_configuration has been renamed to base.group_system.

  • These security groups have changed its module from base to sales_team:

    • base.group_sale_salesman > sales_team.group_sale_salesman.
    • base.group_sale_salesman_all_leads > sales_team.group_sale_salesman_all_leads.
    • base.group_sale_manager > sales_team.group_sale_manager.

  • Remove the use of workflows (they have disappeared in v11.0).

  • All area configs have been merged on a general res.config.settings model, so you have to adapt your possible settings in your module.

  • For v10 ir.values entries:

    • if they are for showing an option under "Print" or "Actions" dropdown menu, remove the record and just add a field binding_model_id on the ir.actions.act_window linked record. Add binding_type = report if the ir.values had key2 = client_print_multi.

    • if they are for having default values, use instead the model ir.default.

  • If you use reports, report module has been split between base and web

    • Change all references of ir.actions.report.xml by ir.actions.report, as the model has been changed.
    • Replace t-call occurrences of base report templates:
      • report.external_layout > web.external_layout.
      • report.external_layout_header: No direct equivalent. You need to insert the changes inside <div class="header o_clean_header"> element of the web.external_layout_? view, being ? one of the available "themes" (background, boxed, clean and standard in core)
      • report.external_layout_footer: the same as above, but looking inside <div class="footer o_background_footer"> element.
      • report.html_container > web.html_container.
      • report.layout > web.report_layout.
      • report.minimal_layout > web.minimal_layout.

  • Remove group_ids field in ir.config_parameter records, and read/write them with sudo() instead (https://github.com/odoo/odoo/commit/d0ca2d115e8b40308e1ff83bf9e7cc874762fbff).

  • If using widget kanban_state_selection in any view, change it to just state_selection.

  • If you create ir.cron in module setup you have to change:

    • model (string) -> model_id (m2o to model)
    • function (string) + args (string) -> code (eg: model.cron_that_does_something())

  • colors attribute in <tree> tag has been replaced by decoration-* (warning, info, danger...) attributes (bootstrap codes) with the condition as value for each.

  • If you handle dates and datetimes, you might need to adapt your code now that Odoo returns always native Python objects, so no more fields.Date/Datetime.from_string is needed. For converting old style date/datetime strings to Python object, use fields.Date.to_date and fields.Datetime.to_datetime methods.

  • If you overwrite create method (in a new model or in an inherited one), look if you can apply decorator @api.model_create_multi for batch mode creation. See https://www.odoo.com/es_ES/slides/slide/let-s-create-records-faster-602 for more details.

  • If your model uses _parent_store = True, then you should remove parent_left and parent_right fields, and add a new one parent_path = fields.Char(index=True). For providing full support when migrating, a post-migration script should be done calling env['model_name']._parent_store_compute() for filling this new field.

  • All <label> elements in views must have a for="" attribute.

  • All <filter> elements in search views must have a name attribute.

  • All <button> elements in a tree view should have a string attribute for accessibility.

  • Convert your SASS styles to SCSS (if any).

  • Related fields are now read only by default. If your code relies on the default contrary, you should add readonly=False in your field definition.

  • base module has reorganized all the model files to include everything inside models folder. If you import that files, you should change import path. You can automate most of these changes with these bash commands:

find . -type f -name '*.py' | xargs sed -i 's/from odoo.addons.base.res/from odoo.addons.base.models/g'
find . -type f -name '*.py' | xargs sed -i 's/from http://odoo.addons.base.ir/from  odoo.addons.base.models/g'

  • Update code to remove use of deprecated methods.

  • Update code to take advantage of the new features.

  • Do the changes you need to do for making the module work on the new version.

On top of this changes we'll also be checking for PEP8. So I recommend you install the appropiate extension to your IDE. Personally, I use SublimeText3 with SublimeLinter and SublimeLinter-pycodestyle extensions.

PR

As a result we should have a branch based on 12.0 with the complete commit history of the migrated module + your new migration commits.

Create a PR to 12.0, so we can review. Automated tests will be run.

Clone this wiki locally