Contributors mailing list archives
contributors@odoo-community.org
Browse archives
Re: OCA/bank-payment-alternative
by
Alexinux, Alexis de Lattre
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.
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.
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 contributors@odoo-community.org [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 contributors@odoo-community.org 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,
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.”
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
