1. Mailing Lists
  2. Contributors
  3. Re: OCA/bank-payment-alternative

Contributors mailing list archives

[email protected]

Browse archives

Re: OCA/bank-payment-alternative

Re: OCA/bank-payment-alternative

Avatar

Re: OCA/bank-payment-alternative

by
Alexinux, Alexis de Lattre
- 27/06/2025 12:17:31
Hello !

After reading the messages of the last days in this thread, especially on the governance and decision around the creation of OCA/bank-payment-alternative, I'd like to expose a few facts. And, for full transparency, I'll share the emails and votes of the Banking PSC on the decision about the creation of OCA/bank-payment-alternative.

When Odoo v18 was released in october 4th 2024, I rapidly noticed the 2 new native fields "Customer Payment Method" and "Supplier Payment Method" on res.partner and "Preferred Payment Method" on invoices.

On October 15th, BertVGroenendael created a PR [1] to migrate account_payment_mode to v18 without consideration for the question of the 3 new native fields.
I raised the point about the 3 new native fields on October 24th in the v18 migration issue [2] : here is an extract of my message :
<<
We need to take some important decisions before we start the migration to v18. One of the big decision is about the introduction of the notion of payment mode in the "account" module via this commit:
odoo/odoo@cdd1596#diff-a13b3dfd8d9e1c45eee3b202345ad950f6b90db975708ee34b9bff2886f4513d
It seems that Odoo nows considers account.payment.method.line as OCA's account.payment.mode. They added 2 M2O company-dependent fields on res.partner for "Customer Payment Mode" and "Supplier Payment Mode". They added the M2O on account.move. Just like OCA's account.payment.mode, account.payment.method.line has a M2O to account.payment.method.
>>
and I also raised the point on the migration PR : "We first need to decide if we switch account.payment.mode to the new native account.payment.method.line, cf discussion on issue 1364"

On November 13th, Pedro answered on the v18 migration issue giving his opinion on the 3 new native fields : "About replacing account.payment.mode with account.payment.method.line, for me is a total no." One of his arguments against the new native fields was the impossibility to have a variable link between payment method and bank journal, which we have in the OCA module account_payment_mode since I introduced it in v9 during the Sorrento code sprint in Italy.

From there, my strategy was the following : start to develop a new module account_payment_base_oca and migrate account_payment_order and all the modules above it adopting the native datamodel i.e. adopt account.payment.method.line as Payment Mode and see if I am able to implement the variable link between payment mode and bank journal. My idea was the following:
- If I was able to successfully implement it, then I would be in favor of adopting account.payment.method.line. And this concrete example with real code would help convince the OCA banking community to go that way.
- If I was not able to implement it successfully, then I would be in favor of keeping account.payment.mode ; my module account_payment_base_oca would be trashed, all my migration PRs would be closed and all the time that I would have invested in this would be lost... I was ok with that from the beginning.

On january 20th 2025, I created a v18 PR for the module account_payment_base_oca as a "Work in progress" [3] The immediate answer of Pedro was:
<<
Why this? Why didn't you answer to my comment in the issue? I don't want data model changes if they are not justified.
>>
 My answer was the following :
<<
I'm trying to adopt the new datamodel. I'm not saying it's the best choice, but I want to try and see what difficulties I face.
I now have the full stack working: account_payment_base_oca + account_payment_order + account_banking_pain_base + account_banking_sepa_credit_transfer + account_banking_mandate + account_banking_sepa_direct_debit. So I am able to make full scenarios and see the real problems I face and try to address them.
At the moment, it's too early to list them, because I'm currently performing the tests.
>>
Pedro's answer was :
<<
Then we are going to have 2 forks. I don't want that "datamodel", as it's very bad as explained in the migration issue.
>>

My first implementation that would set active=False by default on account.payment.method.line was not good and had bad side-effects. So, on January 30th, I came up with a second implementation (a new commit in the same PR) that added a boolean field "selectable" and added [('selectable', '=', True)] on the domain of the 3 native fields. This second implementation worked fine and the integration in Odoo native fields was good. It is this second implementation that convinced me that it was possible to adopt the 3 native fields in OCA/bank-payment : we could keep the possibility to have a variable link between payment method and bank journals and use the native fields.

On March 26th, Stéphane Bidoul started a discussion in this mailing-list about the future of OCA/bank-payment [4] to move forward on this matter and take a decision.
In his first answer on the same day [5], Pedro expressed again his opposition to adopting the native fields and pushed for a fork:
<<
If you want to go this way, you should start a new module set, with different names, but leave the current ones unaltered.
>>

On April 11th, Virginie organised an online meeting with several developers including Pedro and me, but it ended without agreement.

On April 16th, Pedro merged a PR in v18 that migrated account_payment_mode in OCA/bank-payment [5]. This decision to merge was his decision and he took it alone ; it was a de-facto rejection of my PR [3] with account_payment_base_oca that was using the 3 native fields and a rejection of my 7 other v18 PRs that migrated account_payment_order [6], account_banking_pain_base [7],  account_banking_sepa_credit_transfer [8], account_banking_mandate [9], account_banking_sepa_direct_debit [10], account_banking_mandate_sale [11] and account_payment_sale [12] to v18 using the native fields.

So, following the merge by Pedro of account_payment_mode in OCA/bank-payment v18, the last option if we wanted to continue to work in OCA while adopting the 3 native fields was to create a separate repository and change the name of the modules in this new repository. After discussion with Virginie and other board members, it was clear that the decision to create a separate repository would have to be taken by the banking PSC.

On April 18th, I sent the following email to all the members of the Banking PSC (with Virginie in copy) :
<<
Dear Banking PSC,

This mail is for all the members of the banking PSC, as listed on :
If you spot an error in some email, please report it.

Following the debate started by Stéphane Bidoul on March 26th 2025 in [email protected] [1] on OCA/bank-payment for v18 that received many answers and after the online meeting friday April 11th organised by Virgine, I proposed to create a new repository OCA/bank-payment-native (or any better name) to host the v18 modules that use the native object account.payment.method.line as payment mode, which is the native in Odoo v18 on partners and invoices, cf my message on [email protected] of April 16th 2025 [2].

It's time to take decisions and move forward. Virginie thinks that the decision to create this new  repository OCA/bank-payment-native (or any better name you could suggest) should be taken by the Banking PSC. So I propose this poll [3] to get the opinion of each of you. As it's the beginning of Easter week-end, I suggest to wait until Wednesday April 23rd end of the day to look at the result and see if there are more votes for the creation of a new repo or the opposite.

My personal opinion is that each solution has it's drawbacks:
- creating a second OCA repository for bank payment will split community efforts
- refusing to adopt the native odoo datamodel for payment modes and hiding 3 native fields of the "account" module (2 on partners and 1 on invoice) in OCA/bank-payment 18.0 branch may upset many odoo users and is not common in OCA modules
In the end, creating a new repository OCA/bank-payment-native let OCA users choose what option they think is best for their project. That's why I vote in favor of creating this new OCA repository.


Please come and vote on the link [3]. If you think that we should create a new repository but you don't like the name "bank-payment-native" for the new repo, please vote in favor of the proposal and propose better names by email.

I wish you a nice easter week-end !
>>

2 members of the Banking PSC answered this email : Enric Tobella Alomar and Harald Panten López.
Here was Enric's answer :
<<
Hi everyone,

I think I have expressed my opinion on this topic several times, but I will do it again.

I understand that creating a fork is not the best outcome, but it seems inevitable right now. If we need to create it, I would call it experimental. As I explained several times, the native use of this fields is not the use that you are proposing. For this reason, I would never call it native, as Graeme said, calling it experimental seems a good approach. In any case, my vote is to avoid the creation of this fork.

Just to be clear, I think that some PSC are against this approach, but they have offered their help (Pedro and myself for example) in order to get a a middle solution. Maybe merging the PRs directly was not the best option, but it was clear that it was a "all or nothing" approach from your side as you refused to get a middle solution no matter the comments or problems raised from the other side.

Kind regards,
>>

and here was Harald's answer :

<<
Good afternoon,

First of all, I’d like to thank Alexis for his contribution, as it’s clear he has invested a lot of time in trying to improve one of the key pillars in terms of billing in Odoo.

In my opinion, the best option would have been to reach a consensus between those in favor of keeping the current approach and those supporting a change closer to Odoo’s proposal. When there is no clear majority, nor a significant benefit in making such a major change as the one proposed, I believe the best course is to find common ground and reconsider all points of view—especially considering that other PSC members (Pedro, Enric...) have volunteered to help reach a middle-ground solution.

Given that (for now) consensus is not possible, I agree that a more appropriate name would be "experimental" or something similar.

To conclude, I’d like to share a reflection for all of us: What has happened in recent weeks could happen again in the future (near or distant). If the only possible solution involves creating new repositories, with the risk of duplicating efforts and dividing our focus in our work with the OCA, I believe we are not doing justice to the motto “Making Odoo mightier, together.”
>>

On the voting link I had sent, there were only 2 votes : 1 positive vote from Stéphane Bidoul and 1 positive vote from me.

After this consultation of the Banking PSC, I opened a pull request on OCA/repo-maintainer-conf to create a new repository. After some debate with Pedro and Enric, we eventually agreed to name the repository OCA/bank-payment-alternative.  This PR was approved by Pedro and Enric and merged by Stéphane Bidoul.

On May 16th, I opened an issue on OCA/bank-payment-alternative [14] to decide the new module names. Pedro and Enric expressed their disapproval on my first proposal for the new module names. I eventually found other ideas for module names that took into account the opposition of Pedro and Enric on my first proposal. On May 21th, I sent my 6th proposal for module name ; I was really happy with it and 2 other community members expressed their support for this 6th proposal.

On May 28th, I closed my v18 PRs on OCA/bank-payment and re-created them on OCA/bank-payment-alternative with the new module names, while keeping the commit history.

During the OCA code sprint in Spain at the beginning of June, I made several improvements and code clean-up in the pull requests of OCA/bank-payment-alternative that are detailed on a specific issue [15]. During this code sprint, every time I found a bug that also impacted OCA/bank-payment, I reported the issue to OCA/bank-payment, cf [16] and [17] and, when I found a critical bug in the modules account_banking_sepa_direct_debit and account_banking_sepa_credit_transfer while I was refactoring it for OCA/bank-payment-alternative, I took the time to create a PR to fix it in OCA/bank-payment for the module account_banking_sepa_direct_debit [18] and I explained on the PR for account_banking_sepa_credit_transfer the cause of the problem and how to fix it, cf my review on [19].

On June 20th, we reached the point where all the modules were merged in OCA/bank-payment-alternative and I sent the email to announce it in this mailing-list [20] with the list of changes in the datamodel and the list of new features and fixes.

I hope that this email will help the participants of this thread to have a better view of how the decision was taken and whether the governance was respected or not.

My intention has never been to create a fork. For me, the best solution would have been to stay in OCA/bank-payment and adopt the 3 native fields. I think that the decision to hide the 3 native fields in OCA/bank-payment is a real problem and it makes OCA/bank-payment incompatible with all the community modules that will use those fields (I know that hiding the 3 fields is optional in account_payment_partner, but it's really a mess for users if you have double fields for payment mode on partners). Several people have underlined in this thread that it was the first time that a fork happened inside OCA. That's true, but I think it's also the first time that an OCA module hides 3 native fields on partners/invoices and we should not under-estimate that problem either.




Regards,

Alexis

Reference

OSZAR »