-
-
Notifications
You must be signed in to change notification settings - Fork 699
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migration to version 14.0 #2190
Comments
Hi, I really would like to help on this. As I'm a little aware of using the scripts already done but could you please lead me on a "simple module" so that I can learn properly how to help here. Regards |
@flotho I'm afraid there's still some initial tasks to do before having a "simple module" to build migration scripts:
|
Let me know when I could start. |
OK. This is now on hold, as we are doing the 13.0 migration scripts right now. |
I began this work. Not a lot of time, but it could be ok in a couple of weeks. please ping me if other guys are on that task, to avoid duplicated work. thanks ! |
@legalsylvain we want to apply a PoC where we detach the need of having whole Odoo code in OpenUpgrade, which forces us to maintain a big repository, do manual upstream updates, etc. It will use migration paths. There are several challenges, but it's worth to try. My colleague @yajo will investigate it, but at least not in a month. |
@pedrobaeza ;-) awsome, I'm currently exactly working on such design. @yajo : let me know when you want to work on that point. kind regards. |
I remember that in last odoo Experience, they are talking about that point (the possiblity to add extra migration path), but I don't remember exactly how, and don't find any up to date documentation on the doc part of odoo.com. Any insight is welcome regarding that point. |
See odoo/odoo#32650 |
thanks ! I was rgreping |
amazing, it will be much more simple ... |
Hi team, I using scripts openupgrade_scripts. I setup in config file upgrade_path = /my_folder/OpenUpgrade/openupgrade_scripts/scripts/ and run. I don't see any error in logs. Where I can see migrated database? folder or database ? |
There's still no migration scripts, only architecture, so you can't expect soon any migration possibility. |
oh, thank for comment |
Hi, As I'm totally fan of this module and already migrated v8 - v10 to v12 installation, I really would like to help on proposing migrated modules here on this new architecture that seems really |
Yes, there is, although you don't usually need it, because the work was already done. Just go to https://github.com/OCA/OpenUpgrade/tree/14.0/openupgrade_scripts/scripts and start developing the scripts you want to contribute. Also, the |
Made the switch to 14.0 as default branch for representing that this branch starts to be operational for the simple modules, and now the wheel is started! |
is this post #2190 (comment) up to date or does the folder https://github.com/OCA/OpenUpgrade/tree/14.0/openupgrade_scripts/scripts represents the up to date WIP ? sorry if the question looks weird but in the second case maybe updating the post to reference the forlder could be a good idea. |
It's this post. The folder contains all the modules analysis, having or not migration scripts. |
Thanks @pedrobaeza , |
@flotho we migrate modules in an orderly hierarchical way. The account_debit_note module depends on account, which it's still in WIP. |
The analysis file only denotes changes in the model layout. Only after having all dependencies already "migrated", and studying if there's something to transform, we can say about that module if it's "Nothing to do", or if there's something and develop the migration scripts. Example of change that doesn't have a reflect in the model layout, but required to develop scripts: on v10, you had multiple fragmented quants for each tuple of product, location, serial, etc. On v11, all are together, so we added on OpenUpgrade v11 a "deduplication" tool. |
Hi @MiquelRForgeFlow @pedrobaeza , Thanks for great explanation to both of you. |
Is the "Analysis" an automated process or is it a manual process done by developers ? |
Manual. |
ok, |
I don't know any, and I don't do this process regularly. It's something that @StefanRijnhart and @MiquelRForgeFlow are always in charge, but I insist: it's already done. You don't have to repeat it, and it's not needed for the development of the migration scripts. |
For the record, the noupdate_changes.xml file is generated automatically, but its loading must be added to a migration script manually by a developer. You should also weed out (comment out) any entries that seem unwise to overwrite. In the case of translatable columns that need to be overwritten, any existing translations need to be removed in the pre-migration script so that the new translations are loaded by Odoo. |
Such generic question is not easy to be answered. Please focus it a bit more. |
@pedrobaeza sorry for misunderstanding. I want to contribute for migration. I now undestood new structure for 14 migration. So i can start with any easy (small) module to migrate to 14. |
@rb3606 : you have to work module per module. Work 1 : review existing 14 PR : https://github.com/OCA/OpenUpgrade/pulls?q=is%3Aopen+is%3Apr+milestone%3A14.0 Work 2 : work on new modules :
I recommand to begin to review and test existing PR. kind regards. |
Thanks @legalsylvain let me check with PR then. Do i have to Test PR with my local environment right ? and Review code ? |
They are usually two kind of test :
you can : do it with a demo database or do it with a copy of a production database In the end, report your review in the PR, mentionning which kind of review you did. |
This comment has been minimized.
This comment has been minimized.
web_settings_dashboard module was already deleted. It was moved to base_setup module in version 13 |
No, it should be kept and that's why it's put as |
I'm seeing that it's not included in any script, so it's still pending. |
Is the coverage OK to use migration to v14 on a production DB ? |
Just check your installed modules, and then compare to see if any module is missing. Also, in your migration tests, check flows to see if anything is wrong or missing until you are convinced everything is fine, and then you can proceed to migrate your production DB. |
(del)
means that the module has been removed in this version(add)
means that the module has been added in this version>
means that it has been identified that the module has been renamed to the name below<
means that it has been identified that the module has been rename from the name below->
means that the module has been merged in the module below<-
means that the module is the target where the module below has been mergedaccount_statement_import
modules (additions):
account_facturx
): odoo/odoo@913f22fsale_coupon
): odoo/odoo@afad149website_rating
): odoo/odoo@9e06778base_automation
): odoo/odoo@1266cc7modules (deletions):
account
): odoo/odoo@26175eahr_expense
): odoo/odoo@26175eapurchase
): odoo/odoo@26175eaaccount_edi_facturx
): odoo/odoo@913f22fhr_expense
): odoo/odoo@b25e53ahr_holidays
): odoo/odoo@b8a8ad2hw_drivers
): odoo/odoo@841c016l10n_cn
): odoo/odoo@990f1cbbase_address_extended
): odoo/odoo@ef82574point_of_sale
): odoo/odoo@4242599pos_restaurant
): odoo/odoo@99615ffpoint_of_sale
): odoo/odoo@b2f8170portal_rating
): odoo/odoo@9e06778website
): odoo/odoo@88e910eOther interesting things:
...
The text was updated successfully, but these errors were encountered: