[WIP] odoo2odoo connector framework

[sebalix]

This is a WIP PR, I put the code here if people wants to contribute (any help is welcome!).

There are two base modules (framework):

• odoo2odoo_backend: implements some ConnectorUnit classes to synchronize data between Odoo instances
• odoo2odoo_node: adds new CRUD methods similar to create, read, write
  and unlink to focus on the data and avoid undesirable behavior (custom
  overloads of the standard methods). These new methods can be used by the
  odoo2odoo_backend module to drive a low-level data synchronization.

These modules do nothing by themself, this is just a framework.

And others modules based on them:

• odoo2odoo_ir: manage synchronization of some basic data (like translations)
• odoo2odoo_product: products synchronization (with category, UoM...)

[maljac]

Hi @sebalix,

thanks for your contribution. Great to see interest on this topic.
Maybe you have seen that I already created a PR #1 with the initial code. Honestly I have had not much time to push it further, since my clients are already in production with the code, mainly based on code from #1.

Since @yelizariev (see comment in #1) has also started on migrating the code from #1 to odoo10 I would propose to share the work for version 8 and 10.

What do you think?

[yelizariev]

@sebalix @maljac
I think, we need to combine two pull requests or make a decision to maintain only one approach and close another one.
As for me #5 is not usable until it has product synchronization

[sebalix]

Hi,

The main issue for us about #1 is to handle everything: synchronization mechanism, and piece of data to synchronize (like product.product and res.partner in the base module). It is obvious it has been built to satisfy intercompany needs and common cases. But it was too hard to retrieve this code entirely and base our custom modules on that. The main problem is that it uses exclusively the standard CRUD RPC interface which can triggers side-effects in some scenarii.

I prefer to separate concerns, as the connector does: no mention to any data model in the base modules, first focus on the synchronization mechanism and helper classes for the developers, then build modules on top of that to satisfy a customer need. So to anwser @yelizariev this PR and the related modules will not handle product synchronization directly. now includes a odoo2odoo_product module to handle product synchronization.

For instance, in one of our project, we do not handle data model one by one, we have a generic synchronization logic were the input is a list of models ['product.template', 'product.product', 'ir.translation' ...], and we override the logic for some data models to fix only corner cases (e.g. workflows, or ir.translations which are synchronized automatically for all data models involved, but we do not handle them separately at first).
If you want to export a sale.order.line as an event.event for some reasons, you can do that with these modules (fictive example).

That said, I am not against joining the effort especially for v10, I can close my PR without any problem :) I put this code here for someone which could have been interested on the community ML and to get some feedback (as you did!).

Regards,

[yelizariev]

@sebalix what I wanted to ask is will you add odoo2odoo_product (or named in another way) module (and other modules if needed) to be able sync product in particularly and test the framework in general? And if so, could you give a time estimation for it.
We like your approach and need to decide shall we add such module ourselves or it's better to wait updates from you.

Thank you.

[sebalix]

@yelizariev no we'll not push such module sorry
EDIT: the odoo2odoo_product has been included since my comment :)

[maljac]

@sebalix I understand your issues. As you correctly said, the PR #1 is originated from IC process requirements. Netherless I like your approach (separating concerns). Thus, I think we should try to fix the module structure and merge the "best" of both PRs.

When we agree on the module structure we should start with V8 implementation and build the V10 on top of this. For my customers, V9 is not needed.

[sebalix]

@maljac I would like that, build some base modules and others built on top of them. I don't need v9 neither. We can focus on common Binding, Binder, Mappers, Exporter, Importer classes (I didn't implemented the last one ATM).

There are some points where I am not comfortable like the best way to create a binding record, or to export a record with its dependent relationships with a channel of size 4 (and to avoid a double export of one record). From our side we fixed that by setting a channel of size 1, and each data model has a "computed" priority, the volume of data is not important enough to process jobs in parallel.

I'm not sure to have enough time too, but I can do my best. What do you prefer, updating your PR, mine, or make a new one?

[damendieta]

Hi, is this project been worked on or is it abandoned...

I'd like to use it in v9, but it seems that v9 is not developed yet.

Maybe I can help in a v9 migration.

Thanks a lot.

[hbrunn]

you might be interested in https://github.com/OCA/server-tools/tree/8.0/base_import_odoo

ultimately, I think those two should be merged

[coveralls]

Coverage remained the same at 51.509% when pulling 1d52373 on osiell:8.0-odoo2odoo_framework into 792c9b5 on OCA:8.0.

[coveralls]

Coverage remained the same at 51.6% when pulling 49c8a3c on osiell:8.0-odoo2odoo_framework into 792c9b5 on OCA:8.0.

[sebalix]

Modules odoo2odoo_product and its dependency odoo2odoo_ir added. The first handles products synchronization, and the last is used to sync translations.

[github-actions]

There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this PR to never become stale, please ask a PSC member to apply the "no stale" label.