[16][ADD] odoo_project_migration_injection

[hparfr]

Add / remove module during a migration.

I have a project in v14.0 -> v18.0 with:

• Migration is due to "when it's ready" (next year may be ?)
• The client will close all its point of sale, so no point of sale modules should be migrated; but I want to keep pos modules in the project (because it's still in prod today).
• bank_payment modules will be moved to bank_payment_alternative: not really a "rename" because bank_payment modules will still be available in v18
• there is modules which exist in v18 but not in v14, i want to keep a trace to install them.

For the moment, feeding the list of module to add / rm is a manual process. It doesn't take in account dependencies.

[sebalix]

Sorry didn't spot your PR before, will check that soon

[sebalix]

What I had in mind initially (your feedback is welcome) is to not remove anymore the migration module entries of a project when (re)generating them, but make them persistent.

Then, on the migration module entries (odoo.project.module.migration), add a new migration_action selection field to declare what we want to do with that module in the scope of the migration. We could then pop up a wizard on selected entries to choose what to do with them:

• Keep (default)
• Remove
• Replace by another (set of) module(s)

When validating the wizard, if new modules have to be added among the migration entries, they will, such as we also have a link between replaced/new entries ("Y replaced by X" and "X replacing Y").

The same wizard could also be call to install new modules too (and new entries will be injected, with the "New" status).

At the end, by opening the list of migration entries, we get a clear picture of what we keep, remove, replace and install. A comment could also be stored explaining the motivation etc.

A bit more complicated to implement than your suggestion but easier to read (especially by functional people), by using different colors for instance. What do you think?

[hparfr]

I fear it's fragile.

odoo.project.module.migration for each module in all version should exist ?

Agree about "x remplaced by " and stuff.

[sebalix]

No, only the modules you need for a project (I'm talking about odoo.project.module.migration, not odoo.module.migration that stays untouched here).

[sebalix]

Otherwise we keep your way of declaring the evolutions of modules (stored on odoo.project), in a Migration tab that appears only if the project is a migration one (option to enable?)

[hparfr]

odoo.project.module.migration for each module in all version should exist ?

I didn't precise for the project.

migration v14 -> v18. I don't want to migrate point_of_sale because I will probably remove them before the migration.

I will have :

odoo.project.module.migration | project A | point_of_sale | 15.0 | remove
odoo.project.module.migration | project A | point_of_sale | 16.0 |
odoo.project.module.migration | project A | point_of_sale | 17.0 |
odoo.project.module.migration | project A | point_of_sale | 18.0 |

And
odoo.project.module.migration | project A | custom_pos_x | 15.0 | remove
odoo.project.module.migration | project A | custom_pos_x | 16.0 |
odoo.project.module.migration | project A | custom_pos_x | 17.0 |
odoo.project.module.migration | project A | custom_pos_x | 18.0 |

odoo.project.module.migration | project A | custom_pos_y | 15.0 | remove
odoo.project.module.migration | project A | custom_pos_y | 16.0 |
odoo.project.module.migration | project A | custom_pos_y | 17.0 |
odoo.project.module.migration | project A | custom_pos_y | 18.0 |

and so on ?

[hparfr]

I understood you need multiple migrations paths.

For a v14 to v18 project: 4 migrations paths 14.0->15.0 , 14->16, 14 ->17, 14->18.
Because, I'm running openupgrade on each version and I generate my dependencies, I need a migration path per version. <-- may I misinterpret the meaning of the migration path ?

[sebalix]

Oh right, in the context of OpenUpgrade maybe it makes sense to configure all these migration paths, I don't know... is it really relevant?
Are you migrating all modules in intermediate versions from 14.0 even if you target 18.0? IMO You could configure only the 14.0 -> 18.0 migration path alone.

EDIT: I guess even with OU you are not migrating OCA modules in intermediate versions (that is a lot of work?), you trigger the upgrade of OCA modules only during the last step 18.0, right?

EDIT2: here the main goal is to get a report of what needs to be done, the fact you are maybe integrating intermediate versions in your build doesn't require to setup all migration paths in odoo-repository. If you need migration scripts that could exist in intermediate versions, they will be listed anyway (it's not linked to the configured migration paths), up to you to integrate them the way you want (by putting the intermediate modules in your OU build or only the migration scripts).

[hparfr]

With OpenUpgrade it's needed to run the migration on each version.
I found also it's needed if you migrate with Odoo SA. Because migrations scripts of OCA modules exists only on intermediate versions.

So at the moment, I put in the addon_path all oca stable modules for each versions.

The custom code is migrated only on the target version.

By the way, I don't see the benefit of having a multi-version migration path instead of
having multiple only n->n+1 migration paths.

[sebalix]

The benefit is a computation time reduced a lot :) It takes between 1h and 3h depending on the contributions to scan all repositories each night for instance. More you add migration paths, more migration scans will be triggered when a module is updated in a given version.

And functional profils generally don't care about intermediate versions (it's a technical thing). On our side we never migrate with intermediate version modules, Odoo S.A. does it for std modules, but then at the end of this process you get a DB migrated with all non-migrated modules flagged to upgrade, and up to you to migrate these remaining data.
For OCA with intermediate migration scripts, if relevant we simply copy/paste/adapt it in our migration building tool (that's why such scripts are listed by odoo_repository_migration), jumping from 14.0 to 18.0 directly, like you are doing for the custom code.

But if it works for you to configure all migration paths, it's a good thing, and I guess we should support both workflows.
About that, currently if you need to migrate from 14.0 to 18.0, the "Generate migration data" wizard allows you to set only migration paths starting from 14.0 (let's say "14.0 -> 15.0"), then you are not able to set "15.0 -> 16.0". If you want to provide an option on that wizard to generate intermediate migration paths, go for it!

Now to get back on the initial topic, I understand better why you could have several migration entries in different versions, and starting from there indeed it's complicated to flag some as "To remove" and others not, consistency will be difficult to maintain, so having this configuration directly stored in odoo.project is easier 👍

[hparfr]

ah ah ah; just with 2 users, we already have different understanding :)

Ok, now I see better why you did all these things with migrations scripts. Thanks for these explainations.

[hparfr]

The timeline feature introduced #111
is really good and fit my uses cases. Thanks @sebalix

About my initial need of removing the pos during the migration, I will simply keep a copy of the project and remove the pos from the dependencies of this copy.