Archives
Contributors
-
Re: Product variant price based on calculation using attribute values
I have done exactly this. The concept actually worked in reverse. First it used product configurator, and my own module of mrp dynamic line. From there we created a module similar to compute cost from bom, which computed list from bom then applied pricelist logic.But in basic terms, use the bom components to determine the list price.Le mer. 2 juil. 2025, 02:13, Radovan Skolnik <notifications@odoo-community.org> a écrit :Matt,
thank you for suggestion. While there are plenty options regarding attributes / values / their combinations, I fail to see where I could use those values in formulas to get some special pricing. Maybe I am missing something?
Best regards
Radovan
On utorok 1. júla 2025 15:22:01 CEST Matt Taylor wrote:
> https://github.com/oca/product-configurator [1]
> On Tue, Jul 1, 2025 at 4:43 AM Radovan Skolnik <
> notifications@odoo-community.org [2] > wrote: Hello,
>
> the customer is manufacturing stainless steel shelves and such for kitchens.
> The variants are based on width and length. However there are some optional
> features that can be added which would need some custom calculation logic
> to get their price. Few examples: extra rim on the side: [width] * constant
> extra bottom: [width] * [length] * other_constant
> ...
>
> So generally taking the value(s) of attributes and using them in formula to
> get price for extra attribute. I have seen some commercial modules on
> appstore but I'd obviously rather go with OCA.
>
> Thank you. Best regards
>
> Radovan Skolnik
>
> _______________________________________________
> Mailing-List: https://odoo-community.org/groups/contributors-15 [3]
> Post to: mailto: contributors@odoo-community.org [4]
> Unsubscribe: https://odoo-community.org/groups?unsubscribe [5]
>
>
> _______________________________________________
> Mailing-List: https://odoo-community.org/groups/contributors-15 [6]
> Post to: mailto:contributors@odoo-community.org
> Unsubscribe: https://odoo-community.org/groups?unsubscribe [7]
>
>
>
> [1] https://github.com/oca/product-configurator
> [2] mailto:notifications@odoo-community.org
> [3] https://odoo-community.org/groups/contributors-15
> [4] mailto:contributors@odoo-community.org
> [5] https://odoo-community.org/groups?unsubscribe
> [6] https://odoo-community.org/groups/contributors-15
> [7] https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Graeme Gellatly - 09:51 - 1 Jul 2025 -
Re: Product variant price based on calculation using attribute values
Matt,
thank you for suggestion. While there are plenty options regarding attributes / values / their combinations, I fail to see where I could use those values in formulas to get some special pricing. Maybe I am missing something?
Best regards
Radovan
On utorok 1. júla 2025 15:22:01 CEST Matt Taylor wrote:
> https://github.com/oca/product-configurator [1]
> On Tue, Jul 1, 2025 at 4:43 AM Radovan Skolnik <
> notifications@odoo-community.org [2] > wrote: Hello,
>
> the customer is manufacturing stainless steel shelves and such for kitchens.
> The variants are based on width and length. However there are some optional
> features that can be added which would need some custom calculation logic
> to get their price. Few examples: extra rim on the side: [width] * constant
> extra bottom: [width] * [length] * other_constant
> ...
>
> So generally taking the value(s) of attributes and using them in formula to
> get price for extra attribute. I have seen some commercial modules on
> appstore but I'd obviously rather go with OCA.
>
> Thank you. Best regards
>
> Radovan Skolnik
>
> _______________________________________________
> Mailing-List: https://odoo-community.org/groups/contributors-15 [3]
> Post to: mailto: contributors@odoo-community.org [4]
> Unsubscribe: https://odoo-community.org/groups?unsubscribe [5]
>
>
> _______________________________________________
> Mailing-List: https://odoo-community.org/groups/contributors-15 [6]
> Post to: mailto:contributors@odoo-community.org
> Unsubscribe: https://odoo-community.org/groups?unsubscribe [7]
>
>
>
> [1] https://github.com/oca/product-configurator
> [2] mailto:notifications@odoo-community.org
> [3] https://odoo-community.org/groups/contributors-15
> [4] mailto:contributors@odoo-community.org
> [5] https://odoo-community.org/groups?unsubscribe
> [6] https://odoo-community.org/groups/contributors-15
> [7] https://odoo-community.org/groups?unsubscribe
by Radovan Skolnik - 04:11 - 1 Jul 2025 -
Re: Product variant price based on calculation using attribute values
On Tue, Jul 1, 2025 at 4:43 AM Radovan Skolnik <notifications@odoo-community.org> wrote:Hello,
the customer is manufacturing stainless steel shelves and such for kitchens. The variants are based on width and length. However there are some optional features that can be added which would need some custom calculation logic to get their price. Few examples:
extra rim on the side: [width] * constant
extra bottom: [width] * [length] * other_constant
...
So generally taking the value(s) of attributes and using them in formula to get price for extra attribute. I have seen some commercial modules on appstore but I'd obviously rather go with OCA.
Thank you. Best regards
Radovan Skolnik
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Matt - 03:20 - 1 Jul 2025 -
Product variant price based on calculation using attribute values
Hello,
the customer is manufacturing stainless steel shelves and such for kitchens. The variants are based on width and length. However there are some optional features that can be added which would need some custom calculation logic to get their price. Few examples:
extra rim on the side: [width] * constant
extra bottom: [width] * [length] * other_constant
...
So generally taking the value(s) of attributes and using them in formula to get price for extra attribute. I have seen some commercial modules on appstore but I'd obviously rather go with OCA.
Thank you. Best regards
Radovan Skolnik
by Radovan Skolnik - 12:41 - 1 Jul 2025 -
Re: OCA/bank-payment-alternative
Hi all,I read various emails on this argument (I'm not sure I haven't missed some, so maybe I'm writing an unuseful email) and I'm sad about the way it is going. In Italy we had a similar event in the past, where the decision to fork was made by some people and was a bad moment, however this event made the community stronger.The usual 'open source way' as I know is that the decision has to be taken in a democratic poll from the responsible people, in this case the PSC, nothing to do with the OCA Board.The PSC is this one: https://github.com/orgs/OCA/teams/banking-maintainers and has 13 people, my solution should be to take a survey and to do whatever the result is. The people who are not interested to vote are maybe no more interested to be in the PSC too.Is this option unpracticable?Sergio CoratoIl giorno sab 28 giu 2025 alle ore 17:42 Juan José 'Peco' San Martín <notifications@odoo-community.org> ha scritto:Good weekend everyone.There should be no debate: the PSC must have the final word and full responsibility over the project’s technical direction.The Board’s role should focus on governance, overseeing overall strategy, and providing support, but not on making technical decisions.It’s not the right approach to bypass the PSC. They should reconsider and perhaps run for PSC next time.Anyway, hopefully, we can lower the tone of the discussion and find something positive in all of this.Regards,JJOn Sat, Jun 28, 2025 at 1:51 PM Mignon, Laurent <notifications@odoo-community.org> wrote:Dear OCA community friends,
I am writing this message because what brings us together is now being tested by tensions that, if we are not careful, could divide us much more than just a technical discussion.
Together, we have built a strong community known and respected for its core values: openness, quality, transparency, and respect for everyone’s work. None of us, alone or as a company, can say we are the OCA by ourselves. Our strength is our diversity.
We are here today because of the many hours everyone has given: writing code, reviewing, documenting, discussing, helping each other, and defending the spirit of open source. We must remember that even when we do not agree, we are all here because we believe that together we can do more than alone.
I am sure that no one here wants to hurt others or create conflict. We all want to move forward and find better solutions. But because we care so much and put so much passion and time into our work, it is normal that sometimes we feel hurt or misunderstood.
The fork that is creating tensions now is not just a technical choice, it shows how we deal with disagreements and experiments in a living community. Sometimes they question how we do things or make us uncomfortable.
Nobody wins if we turn a disagreement into a fight or blame each other. And nobody wants to break the important role of the PSC nor the OCA Board, just as we should not close the door to new ideas. IMO, we need both: clear and respected governance, and the freedom to try new things.
If we want to move forward together, we maybe need clear and shared rules:
-
What limits do we want for internal forks (or how can we share experiments under the OCA umbrella)?
-
How do we make sure experiments do not break our common base?
-
How can everyone share their opinion without ignoring the roles we have decided together?
???
I think we should stop the public tension and speak openly together. It could be a very interesting and constructive debate. Why not organize a clear and respectful meeting at the OCA days on this topic?
We owe it to everyone who built this community, and to those who will join tomorrow, to keep trust and respect strong.
We do not have to agree on everything, but we must stay united. And more than anything, we should never forget what each person brings. Without your time, generosity and passion, the OCA would not exist.
Thank you all for what you have already done ... and for what we will build next, together.
Respect, diversity and unity fuel innovation! That also keeps our community strong.
Kind regards,
LaurentOn Sat, Jun 28, 2025 at 10:07 AM Graeme Gellatly <notifications@odoo-community.org> wrote:My apologies, I got some details wrong although I still stand by the general message. Certainly was not my intention, but again my apologies. Believe me when I say I do have sympathy for the difficulties here.tbh I did get sent 2 messages I saw in my notifications on my phone (thanks for the 2am wakups btw), but by the time I got to them they were gone and I have no idea via which platforms they were sent or what they were. I only saw first names and first line but presume it was board members.On Thu, Jun 26, 2025 at 11:26 PM Daniel Reis <notifications@odoo-community.org> wrote:Hello all,
First I would like to thank all community members for voicing their perspectives around the current situation with the oca/bank-payment project. Your commitment to OCA’s long-term success and open collaboration is deeply appreciated.
Reviewing the discussion for a Board Member perspective I feel there are some important notes that need to be made here.
I will not comment on any technical details, nor will I discuss any views on individual attitudes or merits. As a board member, the most important perspective here is on governance integrity, project ownership, and community trust.
Clarifying on project governance, I believe the OCA Board agrees with me if I say the following:
Respect for PSC Authority The OCA Board reaffirms the Project Steering Committee’s (PSC) responsibility and decision-making authority within the scope of their projects. This is foundational to our community governance model and must be preserved.
Transparency and Neutrality of the Board The Board’s role is not to impose technical decisions but to facilitate alignment, mediate conflicts when escalated, and uphold governance structures. We acknowledge that people involved in PSCs can also be Board members, but they are not acting in that capacity, and it does not grant them any particular privileges in those PSCs.
Forks and Innovation Channels While forks are a natural part of open-source ecosystems, “endorsed” forks under the OCA umbrella must be handled transparently, with consensus from relevant PSCs and clear processes.
In face of the above, and on some comments on the email thread, I need to set the record straight:
Let me reaffirm that it is NOT up to the OCA Board to make decisions on the direction of oca/bank-payment project, or any other project governed by a PSC for the matter.
It is solely up to the Banking PSC to make the decisions on the evolution of the project, and how to handle diverging options.
The Board can intervene to facilitate alignment, but the decisions ultimately need to come from the PSC.
Perhaps the PSC needs to meet to clarify the decisions made and the plan for the main and fork repos. A joint written statement can help ensure a shared understanding of those commitments, and avoid misunderstandings. The OCA Board is here to help facilitate this, and our Executive Director, Virginie, can help to ensure total independence on this facilitation.
Thank you Daniel
On 25/06/2025 08:58, Jorge Elena Poblet wrote:
Dear all,
I would like to express my opinion on this matter and propose a perspective that focuses on broader value, community cohesion, and long-term sustainability.
While I recognize that Alexis' code is technically sound, we must also evaluate it in terms of value proposition to the OCA and its ecosystem. In my view, the added value does not outweigh the negative consequences of a fragmented community. The creation of a fork (especially one that causes division) undermines our collective efforts not only in terms of development but also in our market competitiveness as implementation partners offering open-source solutions.
We are not just competing on code quality. We are competing in a global market where alignment, collaboration, and unity are crucial. A divided community weakens our position, and this discord will inevitably impact other critical areas such as sponsorships, memberships, and contributor engagement.
If the OCA board allowed this situation to unfold (or worse, endorsed it) then I firmly believe the OCA board has a responsibility to fix it. That means actively engaging with the involved parties, reestablishing governance boundaries, and restoring trust and unity within the community. We look to the board not only for leadership but also for accountability in upholding the values and processes that bind us.
This is no longer just about a particular module or technical choice. It's about governance, trust, and direction. The cost of internal fragmentation is far higher than the perceived benefits of a controversial code improvement, no matter how well-crafted.
We urgently need to redirect our energy and focus toward strengthening our community, improving our collective output, and reinforcing our presence in the Odoo ecosystem. This is how we compete, how we grow, and how we stay relevant. Let’s not allow internal conflict to derail that mission.
Best regards,
On Wed, Jun 25, 2025 at 8:37 AM Stuart J Mackintosh <notifications@odoo-community.org> wrote:
As well as working with Odoo since 2006 and open Source since 10 years before, I lead a US Open Source foundation. I am an avid supporter of OSC and grateful to all of the contributors.
Normally an observer here, I felt compelled to support Graeme's point that once a governance structure is set up such as PSC, it holds the decision until the PSC is disbanded or leadership is changed. So above any technical argument, governance takes precedence.
The Foundation I lead is the Perl Foundation, well known for the acronym TIMTOWTDI (There Is More Than one Way To Do It) and this holds true in many areas and allows for experiments and empirical improvements, creating the opportunity for constructive arguments. However when on the user face of a successful mature project, there should be one recognised solution - forks etc should all be welcome, however PSC must have authority to recognise what is the official distribution. Once this rule is broken, it becomes very hard to ensure consistency and worst case, leads to core contributors to burn out and exit.
It has been valuable reading the technical exchange on this matter, and concerning to read that there may have been a breach of governance.
Best wishes,
Stuart.
On 24/06/2025 23:12, Graeme Gellatly wrote:
This seems a case of the OCA board overstepping its bounds, and prima facie, appears quite conflicted to boot. When a board can unilaterally override a project leader, this is a problem and it is this behaviour that will lead to senior contributor abandonment. Especially when that project leader has clearly shown a path forward and board members have a vested interest in the alternative. Without this interest a fork was probably avoided altogether (and the new issues this is already creating), and eventually agreement reached, but if it was ultimately deemed necessary, it would have occurred outside the OCA and ultimately converged at some future point.
Pedro and I have had disagreements over the years, and long may they continue. But I was never so churlish to think that just because I thought something was better I could unilaterally sidestep a project leader. Beyond adhering to basic principles of open source governance and mediating, insofar as it does not affect the OCA Project as a whole, this is not a board decision. By its own constitution, such power is vested in the PSC. The board can choose to remove a PSC, but not unilaterally override its decision and historically when such disputes reached the board that was often the consideration. This is Open Source dynamics forever under the "authority follows responsibility" principle.
In this, I can only back him 100%. As the clear leader of this particular project under the responsibility principle, whether you agree with him or not, it is a PSC decision and ultimately the project leader. If years of contribution and merit can be discarded by fiat, then it isn't really open source anymore is it? I ask myself which repo will be next. Certainly for me, if the OCA wishes to abandon these principles, it is not for the better.
On Sat, Jun 21, 2025 at 9:47 PM Pedro M. Baeza <notifications@odoo-community.org> wrote:
There are a lot of people that strongly disagrees with the creation of this fork, that is something with no precedence in OCA, and offered to merge the improvements into the main branch, with the only exception of the point 1 "Adoption of the native object account.payment.method.line as "Payment Method" (replaces the OCA object account.payment.mode)", postponing the decision to version 19 to check with Odoo SA if they expand the usage of that fields, because the so called "native model" is not for that purpose, and the changes that have been made for adopting it as so is deforming even more the standard, but it was miserable ignored. You can see in the same thread the technical reasons to not use such data model, but also the ethical and practical ones, as the fork started on version 16, ignoring all the improvements and bugfixes done meanwhile in 17 (or now announced in this thread as new things, while they were there for a long time thanks to multiple contributors), and also not respecting such contributions attribution, which is one of the main principles of the open source.
I'm deeply disappointed by both the attitude of the people involved, including some board members, and the arbitration done by the OCA itself, and I'm personally commiting to bring the improvements mentioned here that are still pending (obviously, respecting the attribution) to the main OCA/bank-payment branch, so please take all of this into account when you decide which one to use.
Regards._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
Stuart J Mackintosh
Business & digital technology consultant
Open Digital Consulting Co
UK: +44 20 36 27 90 40
FR: +33 1 89 48 00 40
Email: sjm@opendigital.cc
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
Jorge Elena Poblet
Founder & CEO
Binhex
j.elena@binhex.cloud
Office (Spain) : +34 622 40 08 08
Office (USA): +1 561 403 4406Offices:
Miami | 8325 NE 2nd Ave, Miami, FL 33138, United States
Texas | 27027 Westheimer Pkwy Katy, TX 77494, United States
Tenerife | Street Subida al Mayorazgo, 13, Office 15-2
Las Palmas | Edificio Polivalente IV Campus de Tafira Parque Tecnológico de Gran Canaria
Start for free: Try Odoo Community in the cloud This email is confidential and intended only for the recipient. If you are not the intended recipient, please notify the sender and delete it immediately.
Privacy Policy_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
DANIEL REIS
MANAGING PARTNER>> Schedule time on my calendar.
M: +351 919 991 307
E: dreis@OpenSourceIntegrators.com
A: Avenida da República 3000, Estoril Office Center, 2649-517 Cascais![[Logo OpenSourceIntegrators.com]](https://www.opensourceintegrators.com/images/opensource-logo-2022.svg)
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Sergio Corato - 08:56 - 30 Jun 2025 -
-
Re: OCA/bank-payment-alternative
Good weekend everyone.There should be no debate: the PSC must have the final word and full responsibility over the project’s technical direction.The Board’s role should focus on governance, overseeing overall strategy, and providing support, but not on making technical decisions.It’s not the right approach to bypass the PSC. They should reconsider and perhaps run for PSC next time.Anyway, hopefully, we can lower the tone of the discussion and find something positive in all of this.Regards,JJOn Sat, Jun 28, 2025 at 1:51 PM Mignon, Laurent <notifications@odoo-community.org> wrote:Dear OCA community friends,
I am writing this message because what brings us together is now being tested by tensions that, if we are not careful, could divide us much more than just a technical discussion.
Together, we have built a strong community known and respected for its core values: openness, quality, transparency, and respect for everyone’s work. None of us, alone or as a company, can say we are the OCA by ourselves. Our strength is our diversity.
We are here today because of the many hours everyone has given: writing code, reviewing, documenting, discussing, helping each other, and defending the spirit of open source. We must remember that even when we do not agree, we are all here because we believe that together we can do more than alone.
I am sure that no one here wants to hurt others or create conflict. We all want to move forward and find better solutions. But because we care so much and put so much passion and time into our work, it is normal that sometimes we feel hurt or misunderstood.
The fork that is creating tensions now is not just a technical choice, it shows how we deal with disagreements and experiments in a living community. Sometimes they question how we do things or make us uncomfortable.
Nobody wins if we turn a disagreement into a fight or blame each other. And nobody wants to break the important role of the PSC nor the OCA Board, just as we should not close the door to new ideas. IMO, we need both: clear and respected governance, and the freedom to try new things.
If we want to move forward together, we maybe need clear and shared rules:
-
What limits do we want for internal forks (or how can we share experiments under the OCA umbrella)?
-
How do we make sure experiments do not break our common base?
-
How can everyone share their opinion without ignoring the roles we have decided together?
???
I think we should stop the public tension and speak openly together. It could be a very interesting and constructive debate. Why not organize a clear and respectful meeting at the OCA days on this topic?
We owe it to everyone who built this community, and to those who will join tomorrow, to keep trust and respect strong.
We do not have to agree on everything, but we must stay united. And more than anything, we should never forget what each person brings. Without your time, generosity and passion, the OCA would not exist.
Thank you all for what you have already done ... and for what we will build next, together.
Respect, diversity and unity fuel innovation! That also keeps our community strong.
Kind regards,
LaurentOn Sat, Jun 28, 2025 at 10:07 AM Graeme Gellatly <notifications@odoo-community.org> wrote:My apologies, I got some details wrong although I still stand by the general message. Certainly was not my intention, but again my apologies. Believe me when I say I do have sympathy for the difficulties here.tbh I did get sent 2 messages I saw in my notifications on my phone (thanks for the 2am wakups btw), but by the time I got to them they were gone and I have no idea via which platforms they were sent or what they were. I only saw first names and first line but presume it was board members.On Thu, Jun 26, 2025 at 11:26 PM Daniel Reis <notifications@odoo-community.org> wrote:Hello all,
First I would like to thank all community members for voicing their perspectives around the current situation with the oca/bank-payment project. Your commitment to OCA’s long-term success and open collaboration is deeply appreciated.
Reviewing the discussion for a Board Member perspective I feel there are some important notes that need to be made here.
I will not comment on any technical details, nor will I discuss any views on individual attitudes or merits. As a board member, the most important perspective here is on governance integrity, project ownership, and community trust.
Clarifying on project governance, I believe the OCA Board agrees with me if I say the following:
Respect for PSC Authority The OCA Board reaffirms the Project Steering Committee’s (PSC) responsibility and decision-making authority within the scope of their projects. This is foundational to our community governance model and must be preserved.
Transparency and Neutrality of the Board The Board’s role is not to impose technical decisions but to facilitate alignment, mediate conflicts when escalated, and uphold governance structures. We acknowledge that people involved in PSCs can also be Board members, but they are not acting in that capacity, and it does not grant them any particular privileges in those PSCs.
Forks and Innovation Channels While forks are a natural part of open-source ecosystems, “endorsed” forks under the OCA umbrella must be handled transparently, with consensus from relevant PSCs and clear processes.
In face of the above, and on some comments on the email thread, I need to set the record straight:
Let me reaffirm that it is NOT up to the OCA Board to make decisions on the direction of oca/bank-payment project, or any other project governed by a PSC for the matter.
It is solely up to the Banking PSC to make the decisions on the evolution of the project, and how to handle diverging options.
The Board can intervene to facilitate alignment, but the decisions ultimately need to come from the PSC.
Perhaps the PSC needs to meet to clarify the decisions made and the plan for the main and fork repos. A joint written statement can help ensure a shared understanding of those commitments, and avoid misunderstandings. The OCA Board is here to help facilitate this, and our Executive Director, Virginie, can help to ensure total independence on this facilitation.
Thank you Daniel
On 25/06/2025 08:58, Jorge Elena Poblet wrote:
Dear all,
I would like to express my opinion on this matter and propose a perspective that focuses on broader value, community cohesion, and long-term sustainability.
While I recognize that Alexis' code is technically sound, we must also evaluate it in terms of value proposition to the OCA and its ecosystem. In my view, the added value does not outweigh the negative consequences of a fragmented community. The creation of a fork (especially one that causes division) undermines our collective efforts not only in terms of development but also in our market competitiveness as implementation partners offering open-source solutions.
We are not just competing on code quality. We are competing in a global market where alignment, collaboration, and unity are crucial. A divided community weakens our position, and this discord will inevitably impact other critical areas such as sponsorships, memberships, and contributor engagement.
If the OCA board allowed this situation to unfold (or worse, endorsed it) then I firmly believe the OCA board has a responsibility to fix it. That means actively engaging with the involved parties, reestablishing governance boundaries, and restoring trust and unity within the community. We look to the board not only for leadership but also for accountability in upholding the values and processes that bind us.
This is no longer just about a particular module or technical choice. It's about governance, trust, and direction. The cost of internal fragmentation is far higher than the perceived benefits of a controversial code improvement, no matter how well-crafted.
We urgently need to redirect our energy and focus toward strengthening our community, improving our collective output, and reinforcing our presence in the Odoo ecosystem. This is how we compete, how we grow, and how we stay relevant. Let’s not allow internal conflict to derail that mission.
Best regards,
On Wed, Jun 25, 2025 at 8:37 AM Stuart J Mackintosh <notifications@odoo-community.org> wrote:
As well as working with Odoo since 2006 and open Source since 10 years before, I lead a US Open Source foundation. I am an avid supporter of OSC and grateful to all of the contributors.
Normally an observer here, I felt compelled to support Graeme's point that once a governance structure is set up such as PSC, it holds the decision until the PSC is disbanded or leadership is changed. So above any technical argument, governance takes precedence.
The Foundation I lead is the Perl Foundation, well known for the acronym TIMTOWTDI (There Is More Than one Way To Do It) and this holds true in many areas and allows for experiments and empirical improvements, creating the opportunity for constructive arguments. However when on the user face of a successful mature project, there should be one recognised solution - forks etc should all be welcome, however PSC must have authority to recognise what is the official distribution. Once this rule is broken, it becomes very hard to ensure consistency and worst case, leads to core contributors to burn out and exit.
It has been valuable reading the technical exchange on this matter, and concerning to read that there may have been a breach of governance.
Best wishes,
Stuart.
On 24/06/2025 23:12, Graeme Gellatly wrote:
This seems a case of the OCA board overstepping its bounds, and prima facie, appears quite conflicted to boot. When a board can unilaterally override a project leader, this is a problem and it is this behaviour that will lead to senior contributor abandonment. Especially when that project leader has clearly shown a path forward and board members have a vested interest in the alternative. Without this interest a fork was probably avoided altogether (and the new issues this is already creating), and eventually agreement reached, but if it was ultimately deemed necessary, it would have occurred outside the OCA and ultimately converged at some future point.
Pedro and I have had disagreements over the years, and long may they continue. But I was never so churlish to think that just because I thought something was better I could unilaterally sidestep a project leader. Beyond adhering to basic principles of open source governance and mediating, insofar as it does not affect the OCA Project as a whole, this is not a board decision. By its own constitution, such power is vested in the PSC. The board can choose to remove a PSC, but not unilaterally override its decision and historically when such disputes reached the board that was often the consideration. This is Open Source dynamics forever under the "authority follows responsibility" principle.
In this, I can only back him 100%. As the clear leader of this particular project under the responsibility principle, whether you agree with him or not, it is a PSC decision and ultimately the project leader. If years of contribution and merit can be discarded by fiat, then it isn't really open source anymore is it? I ask myself which repo will be next. Certainly for me, if the OCA wishes to abandon these principles, it is not for the better.
On Sat, Jun 21, 2025 at 9:47 PM Pedro M. Baeza <notifications@odoo-community.org> wrote:
There are a lot of people that strongly disagrees with the creation of this fork, that is something with no precedence in OCA, and offered to merge the improvements into the main branch, with the only exception of the point 1 "Adoption of the native object account.payment.method.line as "Payment Method" (replaces the OCA object account.payment.mode)", postponing the decision to version 19 to check with Odoo SA if they expand the usage of that fields, because the so called "native model" is not for that purpose, and the changes that have been made for adopting it as so is deforming even more the standard, but it was miserable ignored. You can see in the same thread the technical reasons to not use such data model, but also the ethical and practical ones, as the fork started on version 16, ignoring all the improvements and bugfixes done meanwhile in 17 (or now announced in this thread as new things, while they were there for a long time thanks to multiple contributors), and also not respecting such contributions attribution, which is one of the main principles of the open source.
I'm deeply disappointed by both the attitude of the people involved, including some board members, and the arbitration done by the OCA itself, and I'm personally commiting to bring the improvements mentioned here that are still pending (obviously, respecting the attribution) to the main OCA/bank-payment branch, so please take all of this into account when you decide which one to use.
Regards._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
Stuart J Mackintosh
Business & digital technology consultant
Open Digital Consulting Co
UK: +44 20 36 27 90 40
FR: +33 1 89 48 00 40
Email: sjm@opendigital.cc
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
Jorge Elena Poblet
Founder & CEO
Binhex
j.elena@binhex.cloud
Office (Spain) : +34 622 40 08 08
Office (USA): +1 561 403 4406Offices:
Miami | 8325 NE 2nd Ave, Miami, FL 33138, United States
Texas | 27027 Westheimer Pkwy Katy, TX 77494, United States
Tenerife | Street Subida al Mayorazgo, 13, Office 15-2
Las Palmas | Edificio Polivalente IV Campus de Tafira Parque Tecnológico de Gran Canaria
Start for free: Try Odoo Community in the cloud This email is confidential and intended only for the recipient. If you are not the intended recipient, please notify the sender and delete it immediately.
Privacy Policy_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
DANIEL REIS
MANAGING PARTNER>> Schedule time on my calendar.
M: +351 919 991 307
E: dreis@OpenSourceIntegrators.com
A: Avenida da República 3000, Estoril Office Center, 2649-517 Cascais
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by peco - 05:41 - 28 Jun 2025 -
-
Re: OCA/bank-payment-alternative
Dear OCA community friends,
I am writing this message because what brings us together is now being tested by tensions that, if we are not careful, could divide us much more than just a technical discussion.
Together, we have built a strong community known and respected for its core values: openness, quality, transparency, and respect for everyone’s work. None of us, alone or as a company, can say we are the OCA by ourselves. Our strength is our diversity.
We are here today because of the many hours everyone has given: writing code, reviewing, documenting, discussing, helping each other, and defending the spirit of open source. We must remember that even when we do not agree, we are all here because we believe that together we can do more than alone.
I am sure that no one here wants to hurt others or create conflict. We all want to move forward and find better solutions. But because we care so much and put so much passion and time into our work, it is normal that sometimes we feel hurt or misunderstood.
The fork that is creating tensions now is not just a technical choice, it shows how we deal with disagreements and experiments in a living community. Sometimes they question how we do things or make us uncomfortable.
Nobody wins if we turn a disagreement into a fight or blame each other. And nobody wants to break the important role of the PSC nor the OCA Board, just as we should not close the door to new ideas. IMO, we need both: clear and respected governance, and the freedom to try new things.
If we want to move forward together, we maybe need clear and shared rules:
-
What limits do we want for internal forks (or how can we share experiments under the OCA umbrella)?
-
How do we make sure experiments do not break our common base?
-
How can everyone share their opinion without ignoring the roles we have decided together?
???
I think we should stop the public tension and speak openly together. It could be a very interesting and constructive debate. Why not organize a clear and respectful meeting at the OCA days on this topic?
We owe it to everyone who built this community, and to those who will join tomorrow, to keep trust and respect strong.
We do not have to agree on everything, but we must stay united. And more than anything, we should never forget what each person brings. Without your time, generosity and passion, the OCA would not exist.
Thank you all for what you have already done ... and for what we will build next, together.
Respect, diversity and unity fuel innovation! That also keeps our community strong.
Kind regards,
LaurentOn Sat, Jun 28, 2025 at 10:07 AM Graeme Gellatly <notifications@odoo-community.org> wrote:My apologies, I got some details wrong although I still stand by the general message. Certainly was not my intention, but again my apologies. Believe me when I say I do have sympathy for the difficulties here.tbh I did get sent 2 messages I saw in my notifications on my phone (thanks for the 2am wakups btw), but by the time I got to them they were gone and I have no idea via which platforms they were sent or what they were. I only saw first names and first line but presume it was board members.On Thu, Jun 26, 2025 at 11:26 PM Daniel Reis <notifications@odoo-community.org> wrote:Hello all,
First I would like to thank all community members for voicing their perspectives around the current situation with the oca/bank-payment project. Your commitment to OCA’s long-term success and open collaboration is deeply appreciated.
Reviewing the discussion for a Board Member perspective I feel there are some important notes that need to be made here.
I will not comment on any technical details, nor will I discuss any views on individual attitudes or merits. As a board member, the most important perspective here is on governance integrity, project ownership, and community trust.
Clarifying on project governance, I believe the OCA Board agrees with me if I say the following:
Respect for PSC Authority The OCA Board reaffirms the Project Steering Committee’s (PSC) responsibility and decision-making authority within the scope of their projects. This is foundational to our community governance model and must be preserved.
Transparency and Neutrality of the Board The Board’s role is not to impose technical decisions but to facilitate alignment, mediate conflicts when escalated, and uphold governance structures. We acknowledge that people involved in PSCs can also be Board members, but they are not acting in that capacity, and it does not grant them any particular privileges in those PSCs.
Forks and Innovation Channels While forks are a natural part of open-source ecosystems, “endorsed” forks under the OCA umbrella must be handled transparently, with consensus from relevant PSCs and clear processes.
In face of the above, and on some comments on the email thread, I need to set the record straight:
Let me reaffirm that it is NOT up to the OCA Board to make decisions on the direction of oca/bank-payment project, or any other project governed by a PSC for the matter.
It is solely up to the Banking PSC to make the decisions on the evolution of the project, and how to handle diverging options.
The Board can intervene to facilitate alignment, but the decisions ultimately need to come from the PSC.
Perhaps the PSC needs to meet to clarify the decisions made and the plan for the main and fork repos. A joint written statement can help ensure a shared understanding of those commitments, and avoid misunderstandings. The OCA Board is here to help facilitate this, and our Executive Director, Virginie, can help to ensure total independence on this facilitation.
Thank you Daniel
On 25/06/2025 08:58, Jorge Elena Poblet wrote:
Dear all,
I would like to express my opinion on this matter and propose a perspective that focuses on broader value, community cohesion, and long-term sustainability.
While I recognize that Alexis' code is technically sound, we must also evaluate it in terms of value proposition to the OCA and its ecosystem. In my view, the added value does not outweigh the negative consequences of a fragmented community. The creation of a fork (especially one that causes division) undermines our collective efforts not only in terms of development but also in our market competitiveness as implementation partners offering open-source solutions.
We are not just competing on code quality. We are competing in a global market where alignment, collaboration, and unity are crucial. A divided community weakens our position, and this discord will inevitably impact other critical areas such as sponsorships, memberships, and contributor engagement.
If the OCA board allowed this situation to unfold (or worse, endorsed it) then I firmly believe the OCA board has a responsibility to fix it. That means actively engaging with the involved parties, reestablishing governance boundaries, and restoring trust and unity within the community. We look to the board not only for leadership but also for accountability in upholding the values and processes that bind us.
This is no longer just about a particular module or technical choice. It's about governance, trust, and direction. The cost of internal fragmentation is far higher than the perceived benefits of a controversial code improvement, no matter how well-crafted.
We urgently need to redirect our energy and focus toward strengthening our community, improving our collective output, and reinforcing our presence in the Odoo ecosystem. This is how we compete, how we grow, and how we stay relevant. Let’s not allow internal conflict to derail that mission.
Best regards,
On Wed, Jun 25, 2025 at 8:37 AM Stuart J Mackintosh <notifications@odoo-community.org> wrote:
As well as working with Odoo since 2006 and open Source since 10 years before, I lead a US Open Source foundation. I am an avid supporter of OSC and grateful to all of the contributors.
Normally an observer here, I felt compelled to support Graeme's point that once a governance structure is set up such as PSC, it holds the decision until the PSC is disbanded or leadership is changed. So above any technical argument, governance takes precedence.
The Foundation I lead is the Perl Foundation, well known for the acronym TIMTOWTDI (There Is More Than one Way To Do It) and this holds true in many areas and allows for experiments and empirical improvements, creating the opportunity for constructive arguments. However when on the user face of a successful mature project, there should be one recognised solution - forks etc should all be welcome, however PSC must have authority to recognise what is the official distribution. Once this rule is broken, it becomes very hard to ensure consistency and worst case, leads to core contributors to burn out and exit.
It has been valuable reading the technical exchange on this matter, and concerning to read that there may have been a breach of governance.
Best wishes,
Stuart.
On 24/06/2025 23:12, Graeme Gellatly wrote:
This seems a case of the OCA board overstepping its bounds, and prima facie, appears quite conflicted to boot. When a board can unilaterally override a project leader, this is a problem and it is this behaviour that will lead to senior contributor abandonment. Especially when that project leader has clearly shown a path forward and board members have a vested interest in the alternative. Without this interest a fork was probably avoided altogether (and the new issues this is already creating), and eventually agreement reached, but if it was ultimately deemed necessary, it would have occurred outside the OCA and ultimately converged at some future point.
Pedro and I have had disagreements over the years, and long may they continue. But I was never so churlish to think that just because I thought something was better I could unilaterally sidestep a project leader. Beyond adhering to basic principles of open source governance and mediating, insofar as it does not affect the OCA Project as a whole, this is not a board decision. By its own constitution, such power is vested in the PSC. The board can choose to remove a PSC, but not unilaterally override its decision and historically when such disputes reached the board that was often the consideration. This is Open Source dynamics forever under the "authority follows responsibility" principle.
In this, I can only back him 100%. As the clear leader of this particular project under the responsibility principle, whether you agree with him or not, it is a PSC decision and ultimately the project leader. If years of contribution and merit can be discarded by fiat, then it isn't really open source anymore is it? I ask myself which repo will be next. Certainly for me, if the OCA wishes to abandon these principles, it is not for the better.
On Sat, Jun 21, 2025 at 9:47 PM Pedro M. Baeza <notifications@odoo-community.org> wrote:
There are a lot of people that strongly disagrees with the creation of this fork, that is something with no precedence in OCA, and offered to merge the improvements into the main branch, with the only exception of the point 1 "Adoption of the native object account.payment.method.line as "Payment Method" (replaces the OCA object account.payment.mode)", postponing the decision to version 19 to check with Odoo SA if they expand the usage of that fields, because the so called "native model" is not for that purpose, and the changes that have been made for adopting it as so is deforming even more the standard, but it was miserable ignored. You can see in the same thread the technical reasons to not use such data model, but also the ethical and practical ones, as the fork started on version 16, ignoring all the improvements and bugfixes done meanwhile in 17 (or now announced in this thread as new things, while they were there for a long time thanks to multiple contributors), and also not respecting such contributions attribution, which is one of the main principles of the open source.
I'm deeply disappointed by both the attitude of the people involved, including some board members, and the arbitration done by the OCA itself, and I'm personally commiting to bring the improvements mentioned here that are still pending (obviously, respecting the attribution) to the main OCA/bank-payment branch, so please take all of this into account when you decide which one to use.
Regards._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
Stuart J Mackintosh
Business & digital technology consultant
Open Digital Consulting Co
UK: +44 20 36 27 90 40
FR: +33 1 89 48 00 40
Email: sjm@opendigital.cc
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
Jorge Elena Poblet
Founder & CEO
Binhex
j.elena@binhex.cloud
Office (Spain) : +34 622 40 08 08
Office (USA): +1 561 403 4406Offices:
Miami | 8325 NE 2nd Ave, Miami, FL 33138, United States
Texas | 27027 Westheimer Pkwy Katy, TX 77494, United States
Tenerife | Street Subida al Mayorazgo, 13, Office 15-2
Las Palmas | Edificio Polivalente IV Campus de Tafira Parque Tecnológico de Gran Canaria
Start for free: Try Odoo Community in the cloud This email is confidential and intended only for the recipient. If you are not the intended recipient, please notify the sender and delete it immediately.
Privacy Policy_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
DANIEL REIS
MANAGING PARTNER>> Schedule time on my calendar.
M: +351 919 991 307
E: dreis@OpenSourceIntegrators.com
A: Avenida da República 3000, Estoril Office Center, 2649-517 Cascais
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Laurent Mignon - 01:50 - 28 Jun 2025 -
-
Re: OCA/bank-payment-alternative
My apologies, I got some details wrong although I still stand by the general message. Certainly was not my intention, but again my apologies. Believe me when I say I do have sympathy for the difficulties here.tbh I did get sent 2 messages I saw in my notifications on my phone (thanks for the 2am wakups btw), but by the time I got to them they were gone and I have no idea via which platforms they were sent or what they were. I only saw first names and first line but presume it was board members.On Thu, Jun 26, 2025 at 11:26 PM Daniel Reis <notifications@odoo-community.org> wrote:
Hello all,
First I would like to thank all community members for voicing their perspectives around the current situation with the oca/bank-payment project. Your commitment to OCA’s long-term success and open collaboration is deeply appreciated.
Reviewing the discussion for a Board Member perspective I feel there are some important notes that need to be made here.
I will not comment on any technical details, nor will I discuss any views on individual attitudes or merits. As a board member, the most important perspective here is on governance integrity, project ownership, and community trust.
Clarifying on project governance, I believe the OCA Board agrees with me if I say the following:
Respect for PSC Authority The OCA Board reaffirms the Project Steering Committee’s (PSC) responsibility and decision-making authority within the scope of their projects. This is foundational to our community governance model and must be preserved.
Transparency and Neutrality of the Board The Board’s role is not to impose technical decisions but to facilitate alignment, mediate conflicts when escalated, and uphold governance structures. We acknowledge that people involved in PSCs can also be Board members, but they are not acting in that capacity, and it does not grant them any particular privileges in those PSCs.
Forks and Innovation Channels While forks are a natural part of open-source ecosystems, “endorsed” forks under the OCA umbrella must be handled transparently, with consensus from relevant PSCs and clear processes.
In face of the above, and on some comments on the email thread, I need to set the record straight:
Let me reaffirm that it is NOT up to the OCA Board to make decisions on the direction of oca/bank-payment project, or any other project governed by a PSC for the matter.
It is solely up to the Banking PSC to make the decisions on the evolution of the project, and how to handle diverging options.
The Board can intervene to facilitate alignment, but the decisions ultimately need to come from the PSC.
Perhaps the PSC needs to meet to clarify the decisions made and the plan for the main and fork repos. A joint written statement can help ensure a shared understanding of those commitments, and avoid misunderstandings. The OCA Board is here to help facilitate this, and our Executive Director, Virginie, can help to ensure total independence on this facilitation.
Thank you Daniel
On 25/06/2025 08:58, Jorge Elena Poblet wrote:
Dear all,
I would like to express my opinion on this matter and propose a perspective that focuses on broader value, community cohesion, and long-term sustainability.
While I recognize that Alexis' code is technically sound, we must also evaluate it in terms of value proposition to the OCA and its ecosystem. In my view, the added value does not outweigh the negative consequences of a fragmented community. The creation of a fork (especially one that causes division) undermines our collective efforts not only in terms of development but also in our market competitiveness as implementation partners offering open-source solutions.
We are not just competing on code quality. We are competing in a global market where alignment, collaboration, and unity are crucial. A divided community weakens our position, and this discord will inevitably impact other critical areas such as sponsorships, memberships, and contributor engagement.
If the OCA board allowed this situation to unfold (or worse, endorsed it) then I firmly believe the OCA board has a responsibility to fix it. That means actively engaging with the involved parties, reestablishing governance boundaries, and restoring trust and unity within the community. We look to the board not only for leadership but also for accountability in upholding the values and processes that bind us.
This is no longer just about a particular module or technical choice. It's about governance, trust, and direction. The cost of internal fragmentation is far higher than the perceived benefits of a controversial code improvement, no matter how well-crafted.
We urgently need to redirect our energy and focus toward strengthening our community, improving our collective output, and reinforcing our presence in the Odoo ecosystem. This is how we compete, how we grow, and how we stay relevant. Let’s not allow internal conflict to derail that mission.
Best regards,
On Wed, Jun 25, 2025 at 8:37 AM Stuart J Mackintosh <notifications@odoo-community.org> wrote:
As well as working with Odoo since 2006 and open Source since 10 years before, I lead a US Open Source foundation. I am an avid supporter of OSC and grateful to all of the contributors.
Normally an observer here, I felt compelled to support Graeme's point that once a governance structure is set up such as PSC, it holds the decision until the PSC is disbanded or leadership is changed. So above any technical argument, governance takes precedence.
The Foundation I lead is the Perl Foundation, well known for the acronym TIMTOWTDI (There Is More Than one Way To Do It) and this holds true in many areas and allows for experiments and empirical improvements, creating the opportunity for constructive arguments. However when on the user face of a successful mature project, there should be one recognised solution - forks etc should all be welcome, however PSC must have authority to recognise what is the official distribution. Once this rule is broken, it becomes very hard to ensure consistency and worst case, leads to core contributors to burn out and exit.
It has been valuable reading the technical exchange on this matter, and concerning to read that there may have been a breach of governance.
Best wishes,
Stuart.
On 24/06/2025 23:12, Graeme Gellatly wrote:
This seems a case of the OCA board overstepping its bounds, and prima facie, appears quite conflicted to boot. When a board can unilaterally override a project leader, this is a problem and it is this behaviour that will lead to senior contributor abandonment. Especially when that project leader has clearly shown a path forward and board members have a vested interest in the alternative. Without this interest a fork was probably avoided altogether (and the new issues this is already creating), and eventually agreement reached, but if it was ultimately deemed necessary, it would have occurred outside the OCA and ultimately converged at some future point.
Pedro and I have had disagreements over the years, and long may they continue. But I was never so churlish to think that just because I thought something was better I could unilaterally sidestep a project leader. Beyond adhering to basic principles of open source governance and mediating, insofar as it does not affect the OCA Project as a whole, this is not a board decision. By its own constitution, such power is vested in the PSC. The board can choose to remove a PSC, but not unilaterally override its decision and historically when such disputes reached the board that was often the consideration. This is Open Source dynamics forever under the "authority follows responsibility" principle.
In this, I can only back him 100%. As the clear leader of this particular project under the responsibility principle, whether you agree with him or not, it is a PSC decision and ultimately the project leader. If years of contribution and merit can be discarded by fiat, then it isn't really open source anymore is it? I ask myself which repo will be next. Certainly for me, if the OCA wishes to abandon these principles, it is not for the better.
On Sat, Jun 21, 2025 at 9:47 PM Pedro M. Baeza <notifications@odoo-community.org> wrote:
There are a lot of people that strongly disagrees with the creation of this fork, that is something with no precedence in OCA, and offered to merge the improvements into the main branch, with the only exception of the point 1 "Adoption of the native object account.payment.method.line as "Payment Method" (replaces the OCA object account.payment.mode)", postponing the decision to version 19 to check with Odoo SA if they expand the usage of that fields, because the so called "native model" is not for that purpose, and the changes that have been made for adopting it as so is deforming even more the standard, but it was miserable ignored. You can see in the same thread the technical reasons to not use such data model, but also the ethical and practical ones, as the fork started on version 16, ignoring all the improvements and bugfixes done meanwhile in 17 (or now announced in this thread as new things, while they were there for a long time thanks to multiple contributors), and also not respecting such contributions attribution, which is one of the main principles of the open source.
I'm deeply disappointed by both the attitude of the people involved, including some board members, and the arbitration done by the OCA itself, and I'm personally commiting to bring the improvements mentioned here that are still pending (obviously, respecting the attribution) to the main OCA/bank-payment branch, so please take all of this into account when you decide which one to use.
Regards._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
Stuart J Mackintosh
Business & digital technology consultant
Open Digital Consulting Co
UK: +44 20 36 27 90 40
FR: +33 1 89 48 00 40
Email: sjm@opendigital.cc
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
Jorge Elena Poblet
Founder & CEO
Binhex
j.elena@binhex.cloud
Office (Spain) : +34 622 40 08 08
Office (USA): +1 561 403 4406Offices:
Miami | 8325 NE 2nd Ave, Miami, FL 33138, United States
Texas | 27027 Westheimer Pkwy Katy, TX 77494, United States
Tenerife | Street Subida al Mayorazgo, 13, Office 15-2
Las Palmas | Edificio Polivalente IV Campus de Tafira Parque Tecnológico de Gran Canaria
Start for free: Try Odoo Community in the cloud This email is confidential and intended only for the recipient. If you are not the intended recipient, please notify the sender and delete it immediately.
Privacy Policy_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
DANIEL REIS
MANAGING PARTNER>> Schedule time on my calendar.
M: +351 919 991 307
E: dreis@OpenSourceIntegrators.com
A: Avenida da República 3000, Estoril Office Center, 2649-517 Cascais
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Graeme Gellatly - 10:06 - 28 Jun 2025 -
Re: OCA/bank-payment-alternative
If there is not already a policy in place to manage situations such as this, I propose that the PSC ask the people on this list who have followed the conversation to give a non-binding private or public vote to the steering committee to show the path that they support, with a reason why (and neither will be challenged). It may be that there is a clear support one way from this community however it is hard for many people to engage with such a deep thread.
If there is such a policy, a review of the OCA guidelines should be conducted to understand if the policy or implementation were not sufficient, and clear direction given to ensure future competitions between features or implementations are dealt with promptly through a clear process. Members who participate in this community therefore are bound to these ways of working and held to account when disagreement occurs.
Should this episode end with the departure of Pedro, it would indicate failure of the management of the community, because people should not be drawn out to this point; it is beyond healthy discord. However with confidence in improved process and governance, it may make it easier for contributors to stay committed, having confidence in the governance and knowing that we have all learned from this experience.
Best wishes,
Stuart.
--
Stuart J Mackintosh
Business & digital technology consultant
Open Digital Consulting Co
UK: +44 20 36 27 90 40
FR: +33 1 89 48 00 40
Email: sjm@opendigital.cc
by Stuart J Mackintosh - 09:26 - 28 Jun 2025 -
Re: OCA/bank-payment-alternative
Hello,Akretion founder here and Odoo full time since 2008, co-created the OCA along with the old "Certified Training Partners" back in 2013, often still topping amongst the top 10 OCA contributors and carrying the hardest Odoo localization (Brazil, larger codebase than TinyERP 4.2, soon larger than Odoo 5, 90% test coverage).Just a word to say, this is a very sad situation. While I trust Alexis about the quality of his incredible work and thank him for leading the French OCA localization, I should say that "skipping a few native fields" is certainly not more condemnable than skipping Odoo odoo versions.Yes at Akretion we largely skept version 9, 11, 13, 15 and 17 and having a better focus on even versions helped us a lot to float the boat.But hell, all that would never be possible if some people were not adopting these odd versions. There would be no working OpenUpgrade path if some major players (including Tecnativa, Dixzmit, Forgeflow) didn't adopt these odoo versions. How many modules would not have made it to v14 if these players (and others like CamptoCamp, Acsone...) didn't bit the bullet for us in v13. Cause yes it's easy to jump on even versions once the "community" did half the work on the odoo versions.And certainly part of the mess is due to Alexis not aligning with the other banking PSCs during versions 15 or 17 and then path diverging at 16 or 18.Again, we know why we skip these odd versions, but skipping them and then pointing the finger to the others for not adopting the "native way" is not something I can agree with sorry.Certainly the "keep throwing shit at the wall until something sticks" roadmap from Odoo, that is sell shit early, fix it years later if they can, or "fake it until you make it", is hardly sustainable for an open source community, but we are all trying to cope with it and skipping versions is no better than not adopting what is often just "shit at the wall" early on.Moreover, there are other cases very major cases were Pedro was the first to push important native refactors (or "innovation" if you like) in account_payment_order:Finally, I think some people do not follow the Github OCA notifications and don't have a clear vision about the INCREDIBLE AMOUNT of WORK done in the OCA by the so called dictator Pedro Baeza, and even Enric from Dixmit or other people supporting the legacy OCA/account-banking way.Yeah, it's easy to point the finger to Pedro and many people may not like that he did a negative review of their PR. But I think the guys from Acsone just don't accept either untested or sub-optimal code that Pedro uses to block. It's just that Pedro does reviews at a scale nobody does so it's easy to point him as "the bad guy" of the OCA.But my important point here is: we should stop behaving as spoiled children here. Without Pedro I think we would all be trapped in bullshit jobs running after our Odoo Enterprise licenses monthly sale targets until Odoo investors kill us one by one as they did with all their serious "partners", most of them not even there anymore to warn the next lemmings.Before making critics to Pedro and people like Enric, people should REALLY be aware of what it mean to achieve these contributions figures years after years after years:People who do not follow the Github notifications and think work only happens during the official meetings are just not getting the big picture.So once you understand our whole OCA thing relies on people like Pedro, I think you should adjust to make it easier, not harder for these guys.And people saying "if Pedro were not doing it, others would do it, it would be more democratic", Sorry but I call that wishful thinking from people not used to running open source projects.If no converging way can be achieved, at least I think people behind the fork should assume to work to minimize the impact. For instance, help extract payment_order_dependencies in other repos, or provide common abstractions they can depend on...About skipping versions: my recommendation at Akretion is even if we keep skipping versions for our projects, we should help migrate the main modules we pretend to be responsible for the odd versions to avoid that kind of situation.So I hope you guys will find the best way, but here are my 2 cents.On Fri, Jun 27, 2025 at 10:32 AM Enric Tobella Alomar <notifications@odoo-community.org> wrote:--Alexis,You removed all history from 17 and part of 16. Some of the fixes that you made were already done by other people.I am just analyzing https://github.com/OCA/bank-payment-alternative/pull/5. The same might happen with all other modules of your alternative, but I don't have the energy or time to do it...Just to start: you didn't rewrite the history. Commits will be lost on next migration (removing people attribution in the next migration, not now...)We shared with you how to do it here in a non-blocking review (we didn't want to block your job): https://github.com/OCA/bank-payment-alternative/pull/5#pullrequestreview-2931804750About removing people attribution: I will raise 2 small examples because it takes time to compare.- https://github.com/OCA/bank-payment/commit/e43d4bc45b1693db6fd95665d47b095334ef267c#diff-9a169df5110d406a72c04ed6f7444122f52423112f5ddb1c2c199e619b35f60a was included directly by your commit https://github.com/OCA/bank-payment-alternative/commit/76f7432fde71daa1d26e8bbed527690cee4e819b- https://github.com/OCA/bank-payment/commit/1d37132360fae0d8b6d3204e63007862f3325922 was lost. It improved how it was handled the tests but you ignored it...Do you need more examples?My recomendation would be: "check the history of branch 17"Enric Tobella AlomarCEO & Founder_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Raphaël ValyiFounder and consultant
by Raphaël Akretion - 07:20 - 27 Jun 2025 -
Re: OCA/bank-payment-alternative
Alexis, your email is very difficult to be followed, especially with no text formatting nor inline links, but you are stating some lies directly: when you say that I merged the module on my own, that's absolutely false. Previously, after the meeting we had having Virginie as "mediator", both Enric and me makes 3 explicit propositions:- Contact Odoo SA for knowing their plans expanding the usage of the 2 fields in res.partner. For now, in 18 and master, both fields are only used for pre-selecting a journal in the "Register payment" wizard, which is barely nothing.- Do the surgery extraction of his improvements on the XML export code (and other possible direct improvements) over the current 18.0 branch.- Delay the decision of adopting that 2 fields for the next version, depending on the answer in C1.And you said that you have to think about it. After that, without giving an answer, you started the fork petition. That's when we started to merge the existing work.It's very easy to say "I don't want a fork", but not resigning any of the things you want to get. The fact is that your conditions are: put my fork in 18, or nothing, let's go for the fork. That doesn't allow any margin to negotiation. And everything on this came from the fact that you deviated all your customers in 16 to your previous fork, and now you want to impose the whole OCA your agenda.I'm still willing to converge the work in the terms we proposed in the meeting, even if it implies a lot of work on my side, apart from the already lost in all these attempts to get to an agreement. If not, I'm seriously thinking of abandoning OCA, and continuing on my own, focusing again on delivering high quality open Odoo modules, instead of losing a lot of time (and moreover, energy) in this, and in a asymmetric way, where I have to justify a lot of things against someone that is not giving the same to OCA as me and my organization. Another point to increase this feeling is the reply from Daniel, that states IMO the OCA board governance incompetence to handle these kinds of things, so I don't feel any advantage of doing things inside OCA, if at the end, I'm on my own on any trouble I find inside it. Neutrality doesn't serve here.Regards.
by Pedro M. Baeza - 01:26 - 27 Jun 2025 -
Re: OCA/bank-payment-alternative
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 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 modulesIn 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
by Alexis de Lattre - 12:25 - 27 Jun 2025 -
Re: OCA/bank-payment-alternative
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 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 modulesIn 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
by Alexis de Lattre - 12:25 - 27 Jun 2025 -
Re: OCA/bank-payment-alternative
--Alexis,You removed all history from 17 and part of 16. Some of the fixes that you made were already done by other people.I am just analyzing https://github.com/OCA/bank-payment-alternative/pull/5. The same might happen with all other modules of your alternative, but I don't have the energy or time to do it...Just to start: you didn't rewrite the history. Commits will be lost on next migration (removing people attribution in the next migration, not now...)We shared with you how to do it here in a non-blocking review (we didn't want to block your job): https://github.com/OCA/bank-payment-alternative/pull/5#pullrequestreview-2931804750About removing people attribution: I will raise 2 small examples because it takes time to compare.- https://github.com/OCA/bank-payment/commit/e43d4bc45b1693db6fd95665d47b095334ef267c#diff-9a169df5110d406a72c04ed6f7444122f52423112f5ddb1c2c199e619b35f60a was included directly by your commit https://github.com/OCA/bank-payment-alternative/commit/76f7432fde71daa1d26e8bbed527690cee4e819b- https://github.com/OCA/bank-payment/commit/1d37132360fae0d8b6d3204e63007862f3325922 was lost. It improved how it was handled the tests but you ignored it...Do you need more examples?My recomendation would be: "check the history of branch 17"Enric Tobella AlomarCEO & Founder
by Enric Tobella Alomar - 12:24 - 27 Jun 2025 -
Re: OCA/bank-payment-alternative
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 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 modulesIn 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 was 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,AlexisLe jeu. 26 juin 2025 à 13:26, Daniel Reis <notifications@odoo-community.org> a écrit :Hello all,
First I would like to thank all community members for voicing their perspectives around the current situation with the oca/bank-payment project. Your commitment to OCA’s long-term success and open collaboration is deeply appreciated.
Reviewing the discussion for a Board Member perspective I feel there are some important notes that need to be made here.
I will not comment on any technical details, nor will I discuss any views on individual attitudes or merits. As a board member, the most important perspective here is on governance integrity, project ownership, and community trust.
Clarifying on project governance, I believe the OCA Board agrees with me if I say the following:
Respect for PSC Authority The OCA Board reaffirms the Project Steering Committee’s (PSC) responsibility and decision-making authority within the scope of their projects. This is foundational to our community governance model and must be preserved.
Transparency and Neutrality of the Board The Board’s role is not to impose technical decisions but to facilitate alignment, mediate conflicts when escalated, and uphold governance structures. We acknowledge that people involved in PSCs can also be Board members, but they are not acting in that capacity, and it does not grant them any particular privileges in those PSCs.
Forks and Innovation Channels While forks are a natural part of open-source ecosystems, “endorsed” forks under the OCA umbrella must be handled transparently, with consensus from relevant PSCs and clear processes.
In face of the above, and on some comments on the email thread, I need to set the record straight:
Let me reaffirm that it is NOT up to the OCA Board to make decisions on the direction of oca/bank-payment project, or any other project governed by a PSC for the matter.
It is solely up to the Banking PSC to make the decisions on the evolution of the project, and how to handle diverging options.
The Board can intervene to facilitate alignment, but the decisions ultimately need to come from the PSC.
Perhaps the PSC needs to meet to clarify the decisions made and the plan for the main and fork repos. A joint written statement can help ensure a shared understanding of those commitments, and avoid misunderstandings. The OCA Board is here to help facilitate this, and our Executive Director, Virginie, can help to ensure total independence on this facilitation.
Thank you Daniel
On 25/06/2025 08:58, Jorge Elena Poblet wrote:
Dear all,
I would like to express my opinion on this matter and propose a perspective that focuses on broader value, community cohesion, and long-term sustainability.
While I recognize that Alexis' code is technically sound, we must also evaluate it in terms of value proposition to the OCA and its ecosystem. In my view, the added value does not outweigh the negative consequences of a fragmented community. The creation of a fork (especially one that causes division) undermines our collective efforts not only in terms of development but also in our market competitiveness as implementation partners offering open-source solutions.
We are not just competing on code quality. We are competing in a global market where alignment, collaboration, and unity are crucial. A divided community weakens our position, and this discord will inevitably impact other critical areas such as sponsorships, memberships, and contributor engagement.
If the OCA board allowed this situation to unfold (or worse, endorsed it) then I firmly believe the OCA board has a responsibility to fix it. That means actively engaging with the involved parties, reestablishing governance boundaries, and restoring trust and unity within the community. We look to the board not only for leadership but also for accountability in upholding the values and processes that bind us.
This is no longer just about a particular module or technical choice. It's about governance, trust, and direction. The cost of internal fragmentation is far higher than the perceived benefits of a controversial code improvement, no matter how well-crafted.
We urgently need to redirect our energy and focus toward strengthening our community, improving our collective output, and reinforcing our presence in the Odoo ecosystem. This is how we compete, how we grow, and how we stay relevant. Let’s not allow internal conflict to derail that mission.
Best regards,
On Wed, Jun 25, 2025 at 8:37 AM Stuart J Mackintosh <notifications@odoo-community.org> wrote:
As well as working with Odoo since 2006 and open Source since 10 years before, I lead a US Open Source foundation. I am an avid supporter of OSC and grateful to all of the contributors.
Normally an observer here, I felt compelled to support Graeme's point that once a governance structure is set up such as PSC, it holds the decision until the PSC is disbanded or leadership is changed. So above any technical argument, governance takes precedence.
The Foundation I lead is the Perl Foundation, well known for the acronym TIMTOWTDI (There Is More Than one Way To Do It) and this holds true in many areas and allows for experiments and empirical improvements, creating the opportunity for constructive arguments. However when on the user face of a successful mature project, there should be one recognised solution - forks etc should all be welcome, however PSC must have authority to recognise what is the official distribution. Once this rule is broken, it becomes very hard to ensure consistency and worst case, leads to core contributors to burn out and exit.
It has been valuable reading the technical exchange on this matter, and concerning to read that there may have been a breach of governance.
Best wishes,
Stuart.
On 24/06/2025 23:12, Graeme Gellatly wrote:
This seems a case of the OCA board overstepping its bounds, and prima facie, appears quite conflicted to boot. When a board can unilaterally override a project leader, this is a problem and it is this behaviour that will lead to senior contributor abandonment. Especially when that project leader has clearly shown a path forward and board members have a vested interest in the alternative. Without this interest a fork was probably avoided altogether (and the new issues this is already creating), and eventually agreement reached, but if it was ultimately deemed necessary, it would have occurred outside the OCA and ultimately converged at some future point.
Pedro and I have had disagreements over the years, and long may they continue. But I was never so churlish to think that just because I thought something was better I could unilaterally sidestep a project leader. Beyond adhering to basic principles of open source governance and mediating, insofar as it does not affect the OCA Project as a whole, this is not a board decision. By its own constitution, such power is vested in the PSC. The board can choose to remove a PSC, but not unilaterally override its decision and historically when such disputes reached the board that was often the consideration. This is Open Source dynamics forever under the "authority follows responsibility" principle.
In this, I can only back him 100%. As the clear leader of this particular project under the responsibility principle, whether you agree with him or not, it is a PSC decision and ultimately the project leader. If years of contribution and merit can be discarded by fiat, then it isn't really open source anymore is it? I ask myself which repo will be next. Certainly for me, if the OCA wishes to abandon these principles, it is not for the better.
On Sat, Jun 21, 2025 at 9:47 PM Pedro M. Baeza <notifications@odoo-community.org> wrote:
There are a lot of people that strongly disagrees with the creation of this fork, that is something with no precedence in OCA, and offered to merge the improvements into the main branch, with the only exception of the point 1 "Adoption of the native object account.payment.method.line as "Payment Method" (replaces the OCA object account.payment.mode)", postponing the decision to version 19 to check with Odoo SA if they expand the usage of that fields, because the so called "native model" is not for that purpose, and the changes that have been made for adopting it as so is deforming even more the standard, but it was miserable ignored. You can see in the same thread the technical reasons to not use such data model, but also the ethical and practical ones, as the fork started on version 16, ignoring all the improvements and bugfixes done meanwhile in 17 (or now announced in this thread as new things, while they were there for a long time thanks to multiple contributors), and also not respecting such contributions attribution, which is one of the main principles of the open source.
I'm deeply disappointed by both the attitude of the people involved, including some board members, and the arbitration done by the OCA itself, and I'm personally commiting to bring the improvements mentioned here that are still pending (obviously, respecting the attribution) to the main OCA/bank-payment branch, so please take all of this into account when you decide which one to use.
Regards._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
Stuart J Mackintosh
Business & digital technology consultant
Open Digital Consulting Co
UK: +44 20 36 27 90 40
FR: +33 1 89 48 00 40
Email: sjm@opendigital.cc
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
Jorge Elena Poblet
Founder & CEO
Binhex
j.elena@binhex.cloud
Office (Spain) : +34 622 40 08 08
Office (USA): +1 561 403 4406Offices:
Miami | 8325 NE 2nd Ave, Miami, FL 33138, United States
Texas | 27027 Westheimer Pkwy Katy, TX 77494, United States
Tenerife | Street Subida al Mayorazgo, 13, Office 15-2
Las Palmas | Edificio Polivalente IV Campus de Tafira Parque Tecnológico de Gran Canaria
Start for free: Try Odoo Community in the cloud This email is confidential and intended only for the recipient. If you are not the intended recipient, please notify the sender and delete it immediately.
Privacy Policy_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
DANIEL REIS
MANAGING PARTNER>> Schedule time on my calendar.
M: +351 919 991 307
E: dreis@OpenSourceIntegrators.com
A: Avenida da República 3000, Estoril Office Center, 2649-517 Cascais
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Alexis de Lattre - 12:24 - 27 Jun 2025 -
Re: OCA/bank-payment-alternative
Looks like a missed such a big
fightthread)) Anyway, long story short: can we have something like a short summary to understand what is needed for the both parties to become happy and the collaboration could go on?Best regards,
Ivan Sokolov
Cetmix Odoo Solutionscetmix.com 
This message is sent using Mail Messages Easy app ----- Original message -----
Date: Jun 26, 2025, 5:06:36 PM
From: Notifications
Subject: Re: OCA/bank-payment-alternativeHi everyone,Honestly, I don't understand certain attitudes of the board and of PSCs in the community. I don't know if the community spirit has been lost and only the business spirit remains.
I've been in OCA for years, and honestly, this environment, decisions, and 0 accountability... it just seems like no one wants to take responsibility for anything, and in the end, OCA is shelved due to the lack of collaboration. A new repository will be opened among and for members who truly want to collaborate appropriately.Greetings,Valentín Vinagre Urteaga
CTO
Sygel Technology S.L
+34 613 04 66 67 
valentin.vinagre@sygel.es 
https://www.sygel.es 
C/ Àlaba 61, 5ª planta, 08005, Barcelona El El jue, 26 jun 2025 a las 13:27, Daniel Reis <notifications@odoo-community.org> escribió:_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
Powered by Messages Easy Pro
by "Ivan Sokolov via Cetmix OÜ" <team@cetmix.com> - 12:24 - 27 Jun 2025 -
Re: OCA/bank-payment-alternative
Hey Valentin,
just to clarify, the Board had no intention of getting mixed up in this until discussions here on the mailing list seemed to take a negative turn. It was then though that by inviting the actors to a meeting to help them decide a constructive way forward, we could let things take a positive turn.
After the meeting, same actors have been stirring up the same argument on the mailing list again even though in the meeting they agreed to the way forward.
And to make it worse, now we get more heated responses and even the Board is being made responsible for the course of events?
It is like, there is a fight on the street and someone tries to intervene, and then that person gets kicked in the head instead :-)
What I think is: everyone can make their argument, and maybe what came out of the meeting is not the best.
But we must try to treat each other with friendliness and respect, and assume each other's good intentions, because I think no-one, not the actors in the feud, not the PSC's, not the Board, is here with bad intentions or "business spirit" or what not. We just have a disagreement about something technical, and maybe a confusion about who gets to decide. But there is absolutely no bad intentions.
-Tom
On 6/26/25 17:06, Valentin Vinagre Urteaga wrote:
Hi everyone,Honestly, I don't understand certain attitudes of the board and of PSCs in the community. I don't know if the community spirit has been lost and only the business spirit remains.
I've been in OCA for years, and honestly, this environment, decisions, and 0 accountability... it just seems like no one wants to take responsibility for anything, and in the end, OCA is shelved due to the lack of collaboration. A new repository will be opened among and for members who truly want to collaborate appropriately.
Greetings,
Valentín Vinagre Urteaga
CTO
Sygel Technology S.L
+34 613 04 66 67 valentin.vinagre@sygel.es https://www.sygel.es C/ Àlaba 61, 5ª planta, 08005, Barcelona
El El jue, 26 jun 2025 a las 13:27, Daniel Reis <notifications@odoo-community.org> escribió:
Hello all,
First I would like to thank all community members for voicing their perspectives around the current situation with the oca/bank-payment project. Your commitment to OCA’s long-term success and open collaboration is deeply appreciated.
Reviewing the discussion for a Board Member perspective I feel there are some important notes that need to be made here.
I will not comment on any technical details, nor will I discuss any views on individual attitudes or merits. As a board member, the most important perspective here is on governance integrity, project ownership, and community trust.
Clarifying on project governance, I believe the OCA Board agrees with me if I say the following:
Respect for PSC Authority The OCA Board reaffirms the Project Steering Committee’s (PSC) responsibility and decision-making authority within the scope of their projects. This is foundational to our community governance model and must be preserved.
Transparency and Neutrality of the Board The Board’s role is not to impose technical decisions but to facilitate alignment, mediate conflicts when escalated, and uphold governance structures. We acknowledge that people involved in PSCs can also be Board members, but they are not acting in that capacity, and it does not grant them any particular privileges in those PSCs.
Forks and Innovation Channels While forks are a natural part of open-source ecosystems, “endorsed” forks under the OCA umbrella must be handled transparently, with consensus from relevant PSCs and clear processes.
In face of the above, and on some comments on the email thread, I need to set the record straight:
Let me reaffirm that it is NOT up to the OCA Board to make decisions on the direction of oca/bank-payment project, or any other project governed by a PSC for the matter.
It is solely up to the Banking PSC to make the decisions on the evolution of the project, and how to handle diverging options.
The Board can intervene to facilitate alignment, but the decisions ultimately need to come from the PSC.
Perhaps the PSC needs to meet to clarify the decisions made and the plan for the main and fork repos. A joint written statement can help ensure a shared understanding of those commitments, and avoid misunderstandings. The OCA Board is here to help facilitate this, and our Executive Director, Virginie, can help to ensure total independence on this facilitation.
Thank you Daniel
On 25/06/2025 08:58, Jorge Elena Poblet wrote:
Dear all,
I would like to express my opinion on this matter and propose a perspective that focuses on broader value, community cohesion, and long-term sustainability.
While I recognize that Alexis' code is technically sound, we must also evaluate it in terms of value proposition to the OCA and its ecosystem. In my view, the added value does not outweigh the negative consequences of a fragmented community. The creation of a fork (especially one that causes division) undermines our collective efforts not only in terms of development but also in our market competitiveness as implementation partners offering open-source solutions.
We are not just competing on code quality. We are competing in a global market where alignment, collaboration, and unity are crucial. A divided community weakens our position, and this discord will inevitably impact other critical areas such as sponsorships, memberships, and contributor engagement.
If the OCA board allowed this situation to unfold (or worse, endorsed it) then I firmly believe the OCA board has a responsibility to fix it. That means actively engaging with the involved parties, reestablishing governance boundaries, and restoring trust and unity within the community. We look to the board not only for leadership but also for accountability in upholding the values and processes that bind us.
This is no longer just about a particular module or technical choice. It's about governance, trust, and direction. The cost of internal fragmentation is far higher than the perceived benefits of a controversial code improvement, no matter how well-crafted.
We urgently need to redirect our energy and focus toward strengthening our community, improving our collective output, and reinforcing our presence in the Odoo ecosystem. This is how we compete, how we grow, and how we stay relevant. Let’s not allow internal conflict to derail that mission.
Best regards,
On Wed, Jun 25, 2025 at 8:37 AM Stuart J Mackintosh <notifications@odoo-community.org> wrote:
As well as working with Odoo since 2006 and open Source since 10 years before, I lead a US Open Source foundation. I am an avid supporter of OSC and grateful to all of the contributors.
Normally an observer here, I felt compelled to support Graeme's point that once a governance structure is set up such as PSC, it holds the decision until the PSC is disbanded or leadership is changed. So above any technical argument, governance takes precedence.
The Foundation I lead is the Perl Foundation, well known for the acronym TIMTOWTDI (There Is More Than one Way To Do It) and this holds true in many areas and allows for experiments and empirical improvements, creating the opportunity for constructive arguments. However when on the user face of a successful mature project, there should be one recognised solution - forks etc should all be welcome, however PSC must have authority to recognise what is the official distribution. Once this rule is broken, it becomes very hard to ensure consistency and worst case, leads to core contributors to burn out and exit.
It has been valuable reading the technical exchange on this matter, and concerning to read that there may have been a breach of governance.
Best wishes,
Stuart.
On 24/06/2025 23:12, Graeme Gellatly wrote:
This seems a case of the OCA board overstepping its bounds, and prima facie, appears quite conflicted to boot. When a board can unilaterally override a project leader, this is a problem and it is this behaviour that will lead to senior contributor abandonment. Especially when that project leader has clearly shown a path forward and board members have a vested interest in the alternative. Without this interest a fork was probably avoided altogether (and the new issues this is already creating), and eventually agreement reached, but if it was ultimately deemed necessary, it would have occurred outside the OCA and ultimately converged at some future point.
Pedro and I have had disagreements over the years, and long may they continue. But I was never so churlish to think that just because I thought something was better I could unilaterally sidestep a project leader. Beyond adhering to basic principles of open source governance and mediating, insofar as it does not affect the OCA Project as a whole, this is not a board decision. By its own constitution, such power is vested in the PSC. The board can choose to remove a PSC, but not unilaterally override its decision and historically when such disputes reached the board that was often the consideration. This is Open Source dynamics forever under the "authority follows responsibility" principle.
In this, I can only back him 100%. As the clear leader of this particular project under the responsibility principle, whether you agree with him or not, it is a PSC decision and ultimately the project leader. If years of contribution and merit can be discarded by fiat, then it isn't really open source anymore is it? I ask myself which repo will be next. Certainly for me, if the OCA wishes to abandon these principles, it is not for the better.
On Sat, Jun 21, 2025 at 9:47 PM Pedro M. Baeza <notifications@odoo-community.org> wrote:
There are a lot of people that strongly disagrees with the creation of this fork, that is something with no precedence in OCA, and offered to merge the improvements into the main branch, with the only exception of the point 1 "Adoption of the native object account.payment.method.line as "Payment Method" (replaces the OCA object account.payment.mode)", postponing the decision to version 19 to check with Odoo SA if they expand the usage of that fields, because the so called "native model" is not for that purpose, and the changes that have been made for adopting it as so is deforming even more the standard, but it was miserable ignored. You can see in the same thread the technical reasons to not use such data model, but also the ethical and practical ones, as the fork started on version 16, ignoring all the improvements and bugfixes done meanwhile in 17 (or now announced in this thread as new things, while they were there for a long time thanks to multiple contributors), and also not respecting such contributions attribution, which is one of the main principles of the open source.
I'm deeply disappointed by both the attitude of the people involved, including some board members, and the arbitration done by the OCA itself, and I'm personally commiting to bring the improvements mentioned here that are still pending (obviously, respecting the attribution) to the main OCA/bank-payment branch, so please take all of this into account when you decide which one to use.
Regards._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
Stuart J Mackintosh
Business & digital technology consultant
Open Digital Consulting Co
UK: +44 20 36 27 90 40
FR: +33 1 89 48 00 40
Email: sjm@opendigital.cc
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
Jorge Elena Poblet
Founder & CEO
Binhex
j.elena@binhex.cloud
Office (Spain) : +34 622 40 08 08
Office (USA): +1 561 403 4406Offices:
Miami | 8325 NE 2nd Ave, Miami, FL 33138, United States
Texas | 27027 Westheimer Pkwy Katy, TX 77494, United States
Tenerife | Street Subida al Mayorazgo, 13, Office 15-2
Las Palmas | Edificio Polivalente IV Campus de Tafira Parque Tecnológico de Gran Canaria Start for free: Try Odoo Community in the cloud This email is confidential and intended only for the recipient. If you are not the intended recipient, please notify the sender and delete it immediately.
Privacy Policy_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
DANIEL REIS
MANAGING PARTNER>> Schedule time on my calendar.
M: +351 919 991 307
E: dreis@OpenSourceIntegrators.com
A: Avenida da República 3000, Estoril Office Center, 2649-517 Cascais _______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Tom Blauwendraat - 12:24 - 27 Jun 2025 -
Re: OCA/bank-payment-alternative
Hello Valentin,
I feel I was not clear enough in my previous message,
I'll repeat that it is not the board's role to overstep the PSC, if this is what is being expected.
If people don't agree with this, then a deep revision on the PSC status needs to be made and approved at a Delegates General Assembly.
To be clear, as far as I can tell, as a result of the discussion had by the Banking PSC members:
- the fork repository has been decided and created by the PSC,
- the existing repository will continue it's current course, so nothing changes technically for the people invested in the current design options.
There are differences remaining on what the technical evolution should look like.
The divergence is not ideal, but this is the nature of open source and collaboration.
We need to gradually work it out.
The key aspect is that the PSC responsible for the project keeps its integrity, stays open for constructive discussions, and makes sound decisions.
Thanks
Daniel
On 26/06/2025 16:06, Valentin Vinagre Urteaga wrote:
Hi everyone,Honestly, I don't understand certain attitudes of the board and of PSCs in the community. I don't know if the community spirit has been lost and only the business spirit remains.
I've been in OCA for years, and honestly, this environment, decisions, and 0 accountability... it just seems like no one wants to take responsibility for anything, and in the end, OCA is shelved due to the lack of collaboration. A new repository will be opened among and for members who truly want to collaborate appropriately.
Greetings,
Valentín Vinagre Urteaga
CTO
Sygel Technology S.L
+34 613 04 66 67 valentin.vinagre@sygel.es https://www.sygel.es C/ Àlaba 61, 5ª planta, 08005, Barcelona
El El jue, 26 jun 2025 a las 13:27, Daniel Reis <notifications@odoo-community.org> escribió:
Hello all,
First I would like to thank all community members for voicing their perspectives around the current situation with the oca/bank-payment project. Your commitment to OCA’s long-term success and open collaboration is deeply appreciated.
Reviewing the discussion for a Board Member perspective I feel there are some important notes that need to be made here.
I will not comment on any technical details, nor will I discuss any views on individual attitudes or merits. As a board member, the most important perspective here is on governance integrity, project ownership, and community trust.
Clarifying on project governance, I believe the OCA Board agrees with me if I say the following:
Respect for PSC Authority The OCA Board reaffirms the Project Steering Committee’s (PSC) responsibility and decision-making authority within the scope of their projects. This is foundational to our community governance model and must be preserved.
Transparency and Neutrality of the Board The Board’s role is not to impose technical decisions but to facilitate alignment, mediate conflicts when escalated, and uphold governance structures. We acknowledge that people involved in PSCs can also be Board members, but they are not acting in that capacity, and it does not grant them any particular privileges in those PSCs.
Forks and Innovation Channels While forks are a natural part of open-source ecosystems, “endorsed” forks under the OCA umbrella must be handled transparently, with consensus from relevant PSCs and clear processes.
In face of the above, and on some comments on the email thread, I need to set the record straight:
Let me reaffirm that it is NOT up to the OCA Board to make decisions on the direction of oca/bank-payment project, or any other project governed by a PSC for the matter.
It is solely up to the Banking PSC to make the decisions on the evolution of the project, and how to handle diverging options.
The Board can intervene to facilitate alignment, but the decisions ultimately need to come from the PSC.
Perhaps the PSC needs to meet to clarify the decisions made and the plan for the main and fork repos. A joint written statement can help ensure a shared understanding of those commitments, and avoid misunderstandings. The OCA Board is here to help facilitate this, and our Executive Director, Virginie, can help to ensure total independence on this facilitation.
Thank you Daniel
On 25/06/2025 08:58, Jorge Elena Poblet wrote:
Dear all,
I would like to express my opinion on this matter and propose a perspective that focuses on broader value, community cohesion, and long-term sustainability.
While I recognize that Alexis' code is technically sound, we must also evaluate it in terms of value proposition to the OCA and its ecosystem. In my view, the added value does not outweigh the negative consequences of a fragmented community. The creation of a fork (especially one that causes division) undermines our collective efforts not only in terms of development but also in our market competitiveness as implementation partners offering open-source solutions.
We are not just competing on code quality. We are competing in a global market where alignment, collaboration, and unity are crucial. A divided community weakens our position, and this discord will inevitably impact other critical areas such as sponsorships, memberships, and contributor engagement.
If the OCA board allowed this situation to unfold (or worse, endorsed it) then I firmly believe the OCA board has a responsibility to fix it. That means actively engaging with the involved parties, reestablishing governance boundaries, and restoring trust and unity within the community. We look to the board not only for leadership but also for accountability in upholding the values and processes that bind us.
This is no longer just about a particular module or technical choice. It's about governance, trust, and direction. The cost of internal fragmentation is far higher than the perceived benefits of a controversial code improvement, no matter how well-crafted.
We urgently need to redirect our energy and focus toward strengthening our community, improving our collective output, and reinforcing our presence in the Odoo ecosystem. This is how we compete, how we grow, and how we stay relevant. Let’s not allow internal conflict to derail that mission.
Best regards,
On Wed, Jun 25, 2025 at 8:37 AM Stuart J Mackintosh <notifications@odoo-community.org> wrote:
As well as working with Odoo since 2006 and open Source since 10 years before, I lead a US Open Source foundation. I am an avid supporter of OSC and grateful to all of the contributors.
Normally an observer here, I felt compelled to support Graeme's point that once a governance structure is set up such as PSC, it holds the decision until the PSC is disbanded or leadership is changed. So above any technical argument, governance takes precedence.
The Foundation I lead is the Perl Foundation, well known for the acronym TIMTOWTDI (There Is More Than one Way To Do It) and this holds true in many areas and allows for experiments and empirical improvements, creating the opportunity for constructive arguments. However when on the user face of a successful mature project, there should be one recognised solution - forks etc should all be welcome, however PSC must have authority to recognise what is the official distribution. Once this rule is broken, it becomes very hard to ensure consistency and worst case, leads to core contributors to burn out and exit.
It has been valuable reading the technical exchange on this matter, and concerning to read that there may have been a breach of governance.
Best wishes,
Stuart.
On 24/06/2025 23:12, Graeme Gellatly wrote:
This seems a case of the OCA board overstepping its bounds, and prima facie, appears quite conflicted to boot. When a board can unilaterally override a project leader, this is a problem and it is this behaviour that will lead to senior contributor abandonment. Especially when that project leader has clearly shown a path forward and board members have a vested interest in the alternative. Without this interest a fork was probably avoided altogether (and the new issues this is already creating), and eventually agreement reached, but if it was ultimately deemed necessary, it would have occurred outside the OCA and ultimately converged at some future point.
Pedro and I have had disagreements over the years, and long may they continue. But I was never so churlish to think that just because I thought something was better I could unilaterally sidestep a project leader. Beyond adhering to basic principles of open source governance and mediating, insofar as it does not affect the OCA Project as a whole, this is not a board decision. By its own constitution, such power is vested in the PSC. The board can choose to remove a PSC, but not unilaterally override its decision and historically when such disputes reached the board that was often the consideration. This is Open Source dynamics forever under the "authority follows responsibility" principle.
In this, I can only back him 100%. As the clear leader of this particular project under the responsibility principle, whether you agree with him or not, it is a PSC decision and ultimately the project leader. If years of contribution and merit can be discarded by fiat, then it isn't really open source anymore is it? I ask myself which repo will be next. Certainly for me, if the OCA wishes to abandon these principles, it is not for the better.
On Sat, Jun 21, 2025 at 9:47 PM Pedro M. Baeza <notifications@odoo-community.org> wrote:
There are a lot of people that strongly disagrees with the creation of this fork, that is something with no precedence in OCA, and offered to merge the improvements into the main branch, with the only exception of the point 1 "Adoption of the native object account.payment.method.line as "Payment Method" (replaces the OCA object account.payment.mode)", postponing the decision to version 19 to check with Odoo SA if they expand the usage of that fields, because the so called "native model" is not for that purpose, and the changes that have been made for adopting it as so is deforming even more the standard, but it was miserable ignored. You can see in the same thread the technical reasons to not use such data model, but also the ethical and practical ones, as the fork started on version 16, ignoring all the improvements and bugfixes done meanwhile in 17 (or now announced in this thread as new things, while they were there for a long time thanks to multiple contributors), and also not respecting such contributions attribution, which is one of the main principles of the open source.
I'm deeply disappointed by both the attitude of the people involved, including some board members, and the arbitration done by the OCA itself, and I'm personally commiting to bring the improvements mentioned here that are still pending (obviously, respecting the attribution) to the main OCA/bank-payment branch, so please take all of this into account when you decide which one to use.
Regards._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
Stuart J Mackintosh
Business & digital technology consultant
Open Digital Consulting Co
UK: +44 20 36 27 90 40
FR: +33 1 89 48 00 40
Email: sjm@opendigital.cc
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
Jorge Elena Poblet
Founder & CEO
Binhex
j.elena@binhex.cloud
Office (Spain) : +34 622 40 08 08
Office (USA): +1 561 403 4406Offices:
Miami | 8325 NE 2nd Ave, Miami, FL 33138, United States
Texas | 27027 Westheimer Pkwy Katy, TX 77494, United States
Tenerife | Street Subida al Mayorazgo, 13, Office 15-2
Las Palmas | Edificio Polivalente IV Campus de Tafira Parque Tecnológico de Gran Canaria Start for free: Try Odoo Community in the cloud This email is confidential and intended only for the recipient. If you are not the intended recipient, please notify the sender and delete it immediately.
Privacy Policy_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
DANIEL REIS
MANAGING PARTNER>> Schedule time on my calendar.
M: +351 919 991 307
E: dreis@OpenSourceIntegrators.com
A: Avenida da República 3000, Estoril Office Center, 2649-517 Cascais _______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
DANIEL REIS
MANAGING PARTNER>> Schedule time on my calendar.
M: +351 919 991 307
E: dreis@OpenSourceIntegrators.com
A: Avenida da República 3000, Estoril Office Center, 2649-517 Cascais
by Daniel Reis - 12:24 - 27 Jun 2025 -
Re: OCA/bank-payment-alternative
Alexis,You removed all history from 17 and part of 16. Some of the fixes that you made were already done by other people.I am just analyzing https://github.com/OCA/bank-payment-alternative/pull/5. The same might happen with all other modules of your alternative, but I don't have the energy or time to do it...Just to start: you didn't rewrite the history. Commits will be lost on next migration (removing people attribution in the next migration, not now...)We shared with you how to do it here in a non-blocking review (we didn't want to block your job): https://github.com/OCA/bank-payment-alternative/pull/5#pullrequestreview-2931804750About removing people attribution: I will raise 2 small examples because it takes time to compare.- https://github.com/OCA/bank-payment/commit/e43d4bc45b1693db6fd95665d47b095334ef267c#diff-9a169df5110d406a72c04ed6f7444122f52423112f5ddb1c2c199e619b35f60a was included directly by your commit https://github.com/OCA/bank-payment-alternative/commit/76f7432fde71daa1d26e8bbed527690cee4e819b- https://github.com/OCA/bank-payment/commit/1d37132360fae0d8b6d3204e63007862f3325922 was lost. It improved how it was handled the tests but you ignored it...Do you need more examples?El jue, 26 jun 2025 a las 17:06, Valentin Vinagre Urteaga (<notifications@odoo-community.org>) escribió:Hi everyone,Honestly, I don't understand certain attitudes of the board and of PSCs in the community. I don't know if the community spirit has been lost and only the business spirit remains.
I've been in OCA for years, and honestly, this environment, decisions, and 0 accountability... it just seems like no one wants to take responsibility for anything, and in the end, OCA is shelved due to the lack of collaboration. A new repository will be opened among and for members who truly want to collaborate appropriately.Greetings,Valentín Vinagre Urteaga
CTO
Sygel Technology S.L
+34 613 04 66 67 valentin.vinagre@sygel.es https://www.sygel.es C/ Àlaba 61, 5ª planta, 08005, Barcelona El El jue, 26 jun 2025 a las 13:27, Daniel Reis <notifications@odoo-community.org> escribió:Hello all,
First I would like to thank all community members for voicing their perspectives around the current situation with the oca/bank-payment project. Your commitment to OCA’s long-term success and open collaboration is deeply appreciated.
Reviewing the discussion for a Board Member perspective I feel there are some important notes that need to be made here.
I will not comment on any technical details, nor will I discuss any views on individual attitudes or merits. As a board member, the most important perspective here is on governance integrity, project ownership, and community trust.
Clarifying on project governance, I believe the OCA Board agrees with me if I say the following:
Respect for PSC Authority The OCA Board reaffirms the Project Steering Committee’s (PSC) responsibility and decision-making authority within the scope of their projects. This is foundational to our community governance model and must be preserved.
Transparency and Neutrality of the Board The Board’s role is not to impose technical decisions but to facilitate alignment, mediate conflicts when escalated, and uphold governance structures. We acknowledge that people involved in PSCs can also be Board members, but they are not acting in that capacity, and it does not grant them any particular privileges in those PSCs.
Forks and Innovation Channels While forks are a natural part of open-source ecosystems, “endorsed” forks under the OCA umbrella must be handled transparently, with consensus from relevant PSCs and clear processes.
In face of the above, and on some comments on the email thread, I need to set the record straight:
Let me reaffirm that it is NOT up to the OCA Board to make decisions on the direction of oca/bank-payment project, or any other project governed by a PSC for the matter.
It is solely up to the Banking PSC to make the decisions on the evolution of the project, and how to handle diverging options.
The Board can intervene to facilitate alignment, but the decisions ultimately need to come from the PSC.
Perhaps the PSC needs to meet to clarify the decisions made and the plan for the main and fork repos. A joint written statement can help ensure a shared understanding of those commitments, and avoid misunderstandings. The OCA Board is here to help facilitate this, and our Executive Director, Virginie, can help to ensure total independence on this facilitation.
Thank you Daniel
On 25/06/2025 08:58, Jorge Elena Poblet wrote:
Dear all,
I would like to express my opinion on this matter and propose a perspective that focuses on broader value, community cohesion, and long-term sustainability.
While I recognize that Alexis' code is technically sound, we must also evaluate it in terms of value proposition to the OCA and its ecosystem. In my view, the added value does not outweigh the negative consequences of a fragmented community. The creation of a fork (especially one that causes division) undermines our collective efforts not only in terms of development but also in our market competitiveness as implementation partners offering open-source solutions.
We are not just competing on code quality. We are competing in a global market where alignment, collaboration, and unity are crucial. A divided community weakens our position, and this discord will inevitably impact other critical areas such as sponsorships, memberships, and contributor engagement.
If the OCA board allowed this situation to unfold (or worse, endorsed it) then I firmly believe the OCA board has a responsibility to fix it. That means actively engaging with the involved parties, reestablishing governance boundaries, and restoring trust and unity within the community. We look to the board not only for leadership but also for accountability in upholding the values and processes that bind us.
This is no longer just about a particular module or technical choice. It's about governance, trust, and direction. The cost of internal fragmentation is far higher than the perceived benefits of a controversial code improvement, no matter how well-crafted.
We urgently need to redirect our energy and focus toward strengthening our community, improving our collective output, and reinforcing our presence in the Odoo ecosystem. This is how we compete, how we grow, and how we stay relevant. Let’s not allow internal conflict to derail that mission.
Best regards,
On Wed, Jun 25, 2025 at 8:37 AM Stuart J Mackintosh <notifications@odoo-community.org> wrote:
As well as working with Odoo since 2006 and open Source since 10 years before, I lead a US Open Source foundation. I am an avid supporter of OSC and grateful to all of the contributors.
Normally an observer here, I felt compelled to support Graeme's point that once a governance structure is set up such as PSC, it holds the decision until the PSC is disbanded or leadership is changed. So above any technical argument, governance takes precedence.
The Foundation I lead is the Perl Foundation, well known for the acronym TIMTOWTDI (There Is More Than one Way To Do It) and this holds true in many areas and allows for experiments and empirical improvements, creating the opportunity for constructive arguments. However when on the user face of a successful mature project, there should be one recognised solution - forks etc should all be welcome, however PSC must have authority to recognise what is the official distribution. Once this rule is broken, it becomes very hard to ensure consistency and worst case, leads to core contributors to burn out and exit.
It has been valuable reading the technical exchange on this matter, and concerning to read that there may have been a breach of governance.
Best wishes,
Stuart.
On 24/06/2025 23:12, Graeme Gellatly wrote:
This seems a case of the OCA board overstepping its bounds, and prima facie, appears quite conflicted to boot. When a board can unilaterally override a project leader, this is a problem and it is this behaviour that will lead to senior contributor abandonment. Especially when that project leader has clearly shown a path forward and board members have a vested interest in the alternative. Without this interest a fork was probably avoided altogether (and the new issues this is already creating), and eventually agreement reached, but if it was ultimately deemed necessary, it would have occurred outside the OCA and ultimately converged at some future point.
Pedro and I have had disagreements over the years, and long may they continue. But I was never so churlish to think that just because I thought something was better I could unilaterally sidestep a project leader. Beyond adhering to basic principles of open source governance and mediating, insofar as it does not affect the OCA Project as a whole, this is not a board decision. By its own constitution, such power is vested in the PSC. The board can choose to remove a PSC, but not unilaterally override its decision and historically when such disputes reached the board that was often the consideration. This is Open Source dynamics forever under the "authority follows responsibility" principle.
In this, I can only back him 100%. As the clear leader of this particular project under the responsibility principle, whether you agree with him or not, it is a PSC decision and ultimately the project leader. If years of contribution and merit can be discarded by fiat, then it isn't really open source anymore is it? I ask myself which repo will be next. Certainly for me, if the OCA wishes to abandon these principles, it is not for the better.
On Sat, Jun 21, 2025 at 9:47 PM Pedro M. Baeza <notifications@odoo-community.org> wrote:
There are a lot of people that strongly disagrees with the creation of this fork, that is something with no precedence in OCA, and offered to merge the improvements into the main branch, with the only exception of the point 1 "Adoption of the native object account.payment.method.line as "Payment Method" (replaces the OCA object account.payment.mode)", postponing the decision to version 19 to check with Odoo SA if they expand the usage of that fields, because the so called "native model" is not for that purpose, and the changes that have been made for adopting it as so is deforming even more the standard, but it was miserable ignored. You can see in the same thread the technical reasons to not use such data model, but also the ethical and practical ones, as the fork started on version 16, ignoring all the improvements and bugfixes done meanwhile in 17 (or now announced in this thread as new things, while they were there for a long time thanks to multiple contributors), and also not respecting such contributions attribution, which is one of the main principles of the open source.
I'm deeply disappointed by both the attitude of the people involved, including some board members, and the arbitration done by the OCA itself, and I'm personally commiting to bring the improvements mentioned here that are still pending (obviously, respecting the attribution) to the main OCA/bank-payment branch, so please take all of this into account when you decide which one to use.
Regards._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
Stuart J Mackintosh
Business & digital technology consultant
Open Digital Consulting Co
UK: +44 20 36 27 90 40
FR: +33 1 89 48 00 40
Email: sjm@opendigital.cc
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
Jorge Elena Poblet
Founder & CEO
Binhex
j.elena@binhex.cloud
Office (Spain) : +34 622 40 08 08
Office (USA): +1 561 403 4406Offices:
Miami | 8325 NE 2nd Ave, Miami, FL 33138, United States
Texas | 27027 Westheimer Pkwy Katy, TX 77494, United States
Tenerife | Street Subida al Mayorazgo, 13, Office 15-2
Las Palmas | Edificio Polivalente IV Campus de Tafira Parque Tecnológico de Gran Canaria
Start for free: Try Odoo Community in the cloud This email is confidential and intended only for the recipient. If you are not the intended recipient, please notify the sender and delete it immediately.
Privacy Policy_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
DANIEL REIS
MANAGING PARTNER>> Schedule time on my calendar.
M: +351 919 991 307
E: dreis@OpenSourceIntegrators.com
A: Avenida da República 3000, Estoril Office Center, 2649-517 Cascais
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Enric Tobella AlomarCEO & Founder
by Enric Tobella Alomar - 12:23 - 27 Jun 2025
