Migration to version 9.0

[pedrobaeza]

Todo

https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-9.0

Dependencies

• product_m2mcategories Migration to version 9.0 product-attribute#100
• connector_ecommerce Migration to version 9.0 connector-ecommerce#26

Modules to migrate

• server_env_magentoerpconnect - Assigned to @SodexisTeam - [MIG][9.0] server env magentoerpconnect #201
• magentoerpconnect by @SodexisTeam in [WIP/MIG][9.0] Migrate magentoerpconnect #210
• magentoerpconnect_pricing
• magentoerpconnect_options_active
• customize_example
• magentoerpconnect_catalog
• magentoerpconnect_order_comment
• magentoerpconnect_export_partner

[jaredkipe]

Warning, incoming rant:
Am I the only one who feels like this rabbit hole is too deep?

To be able to install magentoerpconnect, you need to have connector and connector-ecommerce.
The 'connector-ecommerce' package has dependencies into oca/e-commerce. (e.g. sale_payment_method_automatic_workflow) and oca/sale-workflow (e.g. sale_exceptions)

Both e-commerce and sale-workflow have a ton of modules...!

magentoerpconnect requires 'product_m2mcategories' as well. That is found in oca/product-attribute which also has a ton of modules...!

Now that things are not installable out of the box you have to at least sed all of them to be installable just to try to get it to install. All of them together are ~100 modules, thats 40% of the whole odoo addons directory!

And just when you think you've solved everything.... BAM View error in product_m2mcategories... and back down the rabbit hole you go...

Ironically, I believe at least one potential solution to this would be to make magentoerpconnect more 'modularized' itself. This might be more in line with the modular Odoo vision (e.g. if you just want to sync partners because you are doing a CRM or PM only install), and it would be easier to manage dependencies on a per-module basis (e.g. partners is immune to the 80+ module dependancies for oca/e-commerce, oca/sale-workflow and oca/product-attribute)

[pedrobaeza]

You're starting the house by the roof: you have to migrate the first isolated dependency before (for example, product_m2m_categories), and when done, continue upwards until you have all the dependencies resolved. It's what a migration of such complex piece of software requires. No more, no less.

[jaredkipe]

No, I understand that. I guess my problem is more with the 'all or nothing' kind of setup on the core magentoerpconnect module. Installing it requires a lot of modules, and including core modules that maybe are not desired at the level of integration you are trying to do.

[guewen]

@jaredkipe I don't know any project where you need to synchronize only the partners or only the products with Magento. Generally, business-speaking, it is all-or-nothing. Also, separating a connector in many parts is painful, it really doesn't worth the pain in this case in my opinion.

[jaredkipe]

I understand your position, and the position of the current state of development, so I don't mean any disrespect.

Odoo advertises the ability to gradually convert a company's external services over to Odoo. E.g. by replacing Salesforce/SugarCRM =>CRM&SalesManagement, or Basecamp/JIRA => ProjectManagement. In both of those examples, a partners+products export/sync are desired.

To me, it seems overwhelmingly difficult to assist in moving a module like this one through a version bump when the dependencies spiral to 100 modules that all are 'help wanted'.

I mean, I can fix broken views, but does that mean its 9.0 ready? Especially with things called 'sales-workflow' when the core 'sales-workflow' changed so much?

[rvalyi]

@jaredkipe you have an other option if you cannot eat v9 now: you can go v8 which works well and in 2 or 3 years you migrate to a newer version (but that won't be easy either). You'll always have a newer more shinny version but eventually not all complex modules will be ported at the time you need them. The pace of evolution of Odoo will probably slow down, but untill now it had to evolve so it's the way it is...

[jaredkipe]

@rvalyi Thats not entirely true, I can just comment out depends and data files in __openerp__.py and comment out imports in__init__.py
I could also fork and rewrite it, which was going to be my initial plan but decided that it wasn't in the 'OCA Spirit'.

[rvalyi]

@jaredkipe well yes eventually you could make a subset of it indeed. Eventually that can help the port initiative and your work or part of it could be merged.

[pedrobaeza]

@rvalyi, if he actually makes a fork, he will for sure be alone in his solitaire code. A better strategy is to collaborate to migrate some part of the puzzle (some of the dependencies), announce that to avoid the duplication of efforts, and let others make another piece of this puzzle.

[rvalyi]

@pedrobaeza well surely by migrating a part of interest he might be able to use it for in his own use case even before the whole is migrated, call it a branch rather than a fork...

[pedrobaeza]

Well, for sure he will end up with a very mangled branch that it will be very difficult to integrate in another's work, but OK, this is open source, everyone can take the road he/she wants.

[jaredkipe]

Why would it need to integrate with another's work? If I made it more modular (or rather just stripped out parts I don't want right now) then the solution would stand alone. If someone wanted to use it, great. If I want to use the full module down the road, no problem, I just start using it (or merge back in files/pieces from upstream).

That was my point in coming in here first to propose the CRAZY notion that maybe if there was a 'magentoerpconnector_base' that imported website/metadata and setup the adapters and mappers, that module would ONLY need to depend on the connector. Then modules like 'partner' sync could also stand on their own, requiring only the base. Obviously, the more sales related ones would need more dependencies as they are today. I feel the more modularized design would also make it at least slightly more 'approachable' in terms of, "ok, I want to import giftcards, what does a simple model 'bootstrap' look like?"

I personally would love to discuss things like the sales workflow changes on something a little more fluid like IRC, is there such a thing? I'm subscribed to the 'connectors' mailing list, but I don't feel like that would be any better than continuing the Github off-topic-reply-chain.

[pedrobaeza]

Of course is not a crazy idea, and I encourage you to do it proposing this refactoring to OCA instead, but you started asking about what's needed for a pure migration (not refactoring). There's an IRC channel named #oca on Freenode that you can enter to discuss this deeply.

[jaredkipe]

I may have been ranting a bit, but I am pretty sure I did propose refactoring this module in that way in my original comment. My complaining (after finally getting all the modules in place and installable) may have been louder than my 'helpful' suggestions.

Is there a way to propose this refactoring to the OCA other than just forking, doing it, and making pull requests?

[pedrobaeza]

You can start a separate issue declaring your intentions so pleople can see it, comment on it and maybe even help you 😉 The rest is acting: if you have the PR with the refactoring done, that will be hardly rejected unless you don't follow conventions/guidelines/code quality... Put special attention on the done tests, so you don't remove them in your refactoring (maybe adapt them).

[guewen]

As matter of facts, this type of modularity is very hard to achieve with the connector framework (harder than in Odoo) because you can't use something similar to _inherit to extend class (due to the fact that we have a way to inherit from parent versions of backends). So as far as your idea is great and sound and seems simple conceptually, this is not the way I would take because practically it makes it in fact more complex.

To be complete: not hard to achieve if it is very well separated (Importer of partner in core and Importer of sales orders in an extension could be ok in separate modules, but only if we don't need to "extend" the importer/mapper of partners in the sale extension).

[pedrobaeza]

Good point, @guewen. I didn't remember the connector inheritability issue, so indeed it can be more difficult...

[jaredkipe]

I personally do see them as more or less complete packages that build up to 'sales'. All the proposed modules would still need to cooperate. If 'sales' needed something special in the partner mapping, the partner mapping might just have to support it.

This would seem to be the equivalent problem to, "can I customize the partner mapper to support a completely arbitrary attribute?" If the answer to that isn't "easily", then maybe I missed the whole point of the connector framework!

It seems that backends are a form of DI/IoC. It seems like there would/should be a way for a 'sales' module to import the 'partner' mapper, classically extend it, and re-register it as 'the partner mapper' with the backend. Wishful thinking?

[guewen]

This would seem to be the equivalent problem to, "can I customize the partner mapper to support a completely arbitrary attribute?" If the answer to that isn't "easily", then maybe I missed the whole point of the connector framework!

This is easy when you create a new backend version. It is easy to extend and replace (re-register) a Mapper or an Importer. It is not easy if you can possibly have 2 modules which want to extend the same Mapper for the same backend version as only one of them will win.

It seems that backends are a form of DI/IoC. It seems like there would/should be a way for a 'sales' module to import the 'partner' mapper, classically extend it, and re-register it as 'the partner mapper' with the backend. Wishful thinking?

That's straightforward to do, but only if one addon does it. If you have 2 addons which extend and re-register the partner mapper, you'll have a conflict.

[jaredkipe]

That's straightforward to do, but only if one addon does it. If you have 2 addons which extend and re-register the partner mapper, you'll have a conflict.

How ironic then that Magento itself manages with this scheme ;)
As I'm sure you are aware, anyone is able to replace a model in the IoC Container/factory in Magento, and the only issue with that is that if you have two that both want to extend the same model (or route, or block, whatever), you must then depend/inherit from whatever the current last in the chain is. (Magento also allows you to replace a built in definition though overriding it in a more selective auto-include folder (e.g. /app/code/local/Mage/Customer/Model/..).
An inheritance chain seems appropriate to me because the 'pinnacle' module like 'sales/invoices' would depend implicitly (and thus could extend) the supporting modules like 'partners' and 'products'.

Mixing and matching would be possible to an extent, but not all combinations would be appropriate.

Do you have any practical examples where the importers or mappers would need to be overridden for any of the current functionality?

[guewen]

As I'm sure you are aware

You make me more knowledgeable that I am :-) I don't know how to develop Magento extensions. Should be nasty when 2 addons that you don't own inherit the same model.

Well, if we consider the existing code, yes, it would probably be possible to split it in several addons as you say. I had in head the use case of concurrent addons like sale_x and sale_y which would both inherit the sale importer, but of course this would not be the case in the core addons, we would only have a magentoerpconnect_sale addon.

I understand your reasoning and I like it. It indeed fasten the first migration iterations and allow faster feedbacks for the base synchronisations. I'm only partly convinced though for the following reasons:

• need more work to make the split
• mean that we put more work on the shoulder on the people who created customization addons to adapt to the new scheme (not dramatic though, change some class paths or xmlids)
• anyway the whole needs to be migrated, I never heard of someone who wants to import partners or products but not sales, usually they rather want always more!

[jaredkipe]

Nasty enough to have full extensions dedicated to trying to find and untangle the various intertwined extensions. (one of many http://www.magentocommerce.com/magento-connect/modules-conflict-detector.html )

Not to beat a dead horse, but one of the major 'flaws' in Magento is that it doesn't do a particularly good job at quoting or "direct sales". The idea of Lead->Opportunity->Quote(s)->Sale(s)(back in Magento) is much better in Odoo (or Salesforce), but it can be very hard to just instantly migrate a whole company's workflow over to new software. Plus, you can't really say nobody wants it, because I want it ;)

[jaredkipe]

If there is openeness to this idea, I can make a fork and start working on it. Otherwise, I'm not sure if there is any ongoing work on 9.0 upgrading. I've been in the #oca chat and on the mailing list for connectors, but haven't seen anything going on.

[pedrobaeza]

For me it's OK. What others say?

[stephankeller]

For info, we started looking at porting to V9.0 not sure yet we are going to do it. Just in case others are looking at that as well.

[SodexisTeam]

For info, we are porting server_env_magentoerpconnect from 8.0 to 9.0

[kingofsevens]

@stephankeller did you make any progress? We are thinking on joining the effort.

[stephankeller]

@kingofsevens as you probably know, the connector base module has been ported: https://github.com/OCA/connector. We are working on porting the connector-ecommerce module: http://github.com/OCA/connector-ecommerce, starting with sale_automatic_workflow: OCA/sale-workflow#291. Here is the link to the discussion about that: https://odoo-community.org/groups/contributors-15/contributors-37353?mode=thread&date_begin=&date_end=.
You can start working on magentoerpconnect I guess, although it will be difficult before the work is done in connector-ecommerce. You could also port product_multi_image that is going to be needed. Let us know if you start anything.

[pedrobaeza]

I have improved product_multi_image a bit more in OCA/product-attribute#151, so please take it into account for the migration.

[stephankeller]

@pedrobaeza Noted.

[guewen]

Note that the core magentoerpconnect does not depend product_multi_image.

[kingofsevens]

Sorry for my late return. Can you update all again, where help is needed, we can now spare resources into this.

[SodexisTeam]

For info, we have started [WIP]pull request for magentoerpconnect #210.