[18.0][MIG] connector_ecommerce: Migration to 18.0

[vvrossem]

[MIG][17.0] connector_ecommerce: Migration to 17.0 used as source

Removed dependencies:

• sale_automatic_workflow_payment_mode (glue module of sale_automatic_workflow and account_payment_sale), to use account_payment_sale only

Missing dependencies:

• https://github.com/OCA/bank-payment/pull/1386, depends on:
  • https://github.com/OCA/bank-payment/pull/1401

[gurneyalex]

Hello @vvrossem We would like to split out the dependency on sale automatic workflow from the connector_ecommerce in 18.0. Do you think this would cause issues (for instance if the code for this is tightly coupled inside the module)?

[leemannd]

Warning: you depend on a module that is not merged. It has been superseeded by -> https://github.com/OCA/bank-payment/pull/1447 And the two PRs have huge changes.

[leemannd]

Warning The module account_payment_sale has been merged into a version we don't want. It will be moved to -> https://github.com/OCA/bank-payment-alternative Please don't take in account the module that is currently merged into the branch 18.0.

We have a temporary PR -> https://github.com/OCA/bank-payment-alternative/pull/1

To keep track of the work done. We may want to change the module name (not done for the moment).

[LoisRForgeFlow]

@leemannd FWIW based on the naming mapping provided by Alexis:

account_payment_sale will still remain on the main/original repository, and will have a different name (account_payment_base_oca_sale) in the alternative. Shouldn't you open the migration on the original repo?

[leemannd]

Hello @LoisRForgeFlow @pedrobaeza , Thank you for your inputs.

We will recheck the naming with what has been merged into the repository bank-payment-alternative.

We want to use the module e-commerce and bank-payment-alternative. Unless you have a better proposition, my understanding is that we need to do the same and ask for the creation of a new repository connector-ecommerce-alternative ?

I'm not sure I like this idea and I'm afraid that it will land in the creation of several repositories *-alternative. There is some coherence in it but it feels like it is a bit too much a "fork-war" and my concern is about loosing a global consistency inbetween the OCA repositories/modules.

Unless you have a better input/idea, we will do so.

Rebel modules are only for testing? AFAIR we don't have the possibility to exclude the installation of incompatibles modules. If we had this possibility. I would love to keep two versions of the e-commercemodule into the same repository.

[rvalyi]

This kind of situation certainly sucks... Eventually we might create a third interface account_payment_order module that would kind of abstract away the basic features of the two alternative modules without having a hard dependency on them. This kind of thing has never been done in the OCA and it would certainly be challenging regarding the ORM/framework support and what common features could really be abstracted away in a robust manner. I'm not telling this is the solution here, but eventually such eventualities of modules forks may happen again (while it should be avoided at all costs) and eventually this is something we might need to deal with.

So for instance here is how Debian deals with such situations (though the surface of such interfaces is probably much smaller in the Debian case): https://aistudio.google.com/app/prompts?state=%7B%22ids%22:%5B%2215Sh_xjfl_PkB6wlFScAvqmdyIsQboXvL%22%5D,%22action%22:%22open%22,%22userId%22:%22114418078122921323275%22,%22resourceKeys%22:%7B%7D%7D&usp=sharing cc @pedrobaeza @sbidoul

[pedrobaeza]

Well, the solution is that you come back to sanity and remove the fork, and let's do everything to converge. We are still opened to try solutions, as stated everywhere. If not, doing "interfaces" is only a patch over a patch over a patch...

[hparfr]

This kind of thing has never been done in the OCA

What about https://github.com/OCA/search-engine/tree/16.0/connector_search_engine since v10 ?

[sebastienbeau]

@leemannd just to understand your need of moving to bank-alternative.

If am right you do not use Alexis payment order module right ? You use Enterprise one ? And your purpose here is to

• have the configuration on "account.payment.method.line" (native odoo)
• fill the "preferred_payment_method_line_id'" of the account.move from the sale order so it's more compatible with enterprise, right ? This is why you want to depend on "account_payment_base_oca"

I may have a idea that can avoid a fork here, but before developing the idea, I would like to be sure understand the need.

Thanks for your feedback.

[leemannd]

Hello @alexis-via , You're correct in your assumptions.

[flotho]

Hi @leemannd ,

coul you elaborate your latest answer ? What is the maturity of this PR? Regards

[leemannd]

Hello @simahawk , can you please ping me when you have the message with the clear picture. We are currently in production with it and I'm not fond in "changing" too much what we did. It may cost too much for us given the time we already lost due to the disagreements on this topic.

I'm looking forward for the resolution. But for the moment I may have a strong opinion and I have no issue in multiplying to the infinite the alternatives modules (worst case scenario that I don't want to apply).

[simahawk]

@leemannd we don't want existing modules to be refactored on top of the alternative. You'll have to find a way to support this w/ a glue module or w/ a private fork.

[leemannd]

Hello @flotho , The module is mature and in production.

For the moment we will fork it. Later we may try to find a way to support it in another way. We are currently stopping any work related to it and will not go back to the initial implementation for this module in 18.0