- Mailing Lists
- Contributors
- Re: The future of oca/bank-payment
Archives
- By thread 1419
-
By date
- August 2019 59
- September 2019 118
- October 2019 165
- November 2019 97
- December 2019 35
- January 2020 58
- February 2020 204
- March 2020 121
- April 2020 172
- May 2020 50
- June 2020 158
- July 2020 85
- August 2020 94
- September 2020 193
- October 2020 277
- November 2020 100
- December 2020 159
- January 2021 38
- February 2021 87
- March 2021 146
- April 2021 73
- May 2021 90
- June 2021 86
- July 2021 123
- August 2021 50
- September 2021 68
- October 2021 66
- November 2021 74
- December 2021 75
- January 2022 98
- February 2022 77
- March 2022 68
- April 2022 31
- May 2022 59
- June 2022 87
- July 2022 141
- August 2022 38
- September 2022 73
- October 2022 152
- November 2022 39
- December 2022 50
- January 2023 93
- February 2023 49
- March 2023 106
- April 2023 47
- May 2023 69
- June 2023 92
- July 2023 64
- August 2023 103
- September 2023 91
- October 2023 101
- November 2023 94
- December 2023 46
- January 2024 75
- February 2024 79
- March 2024 104
- April 2024 63
- May 2024 40
- June 2024 160
- July 2024 80
- August 2024 70
- September 2024 62
- October 2024 121
- November 2024 117
- December 2024 89
- January 2025 59
- February 2025 104
- March 2025 96
- April 2025 107
- May 2025 52
- June 2025 72
- July 2025 60
- August 2025 81
- September 2025 124
- October 2025 63
- November 2025 22
Contributors
Re: The future of oca/bank-payment
I have expressed my rejection specifically on this new approach due to a lot of reasons:- It's complicating everything, not easing it.- It requires a lot of effort to adapt to it. Both users and developers need to change all they know.- There's no need for this change.- It's not bringing any value.I have exposed all the detailed reasons on the PRs with no answer from anybody.But it's not only that. It's the continuous contempt of Alexis refusing to follow the general OCA guidelines that we all agreed:- One PR per module migration.- Split changes by batches for being reviewable and debatable.- Not clear commit history.- Etc.And I personally have pinged him tens of times for checking fixes or improvements in this set of modules with 0 answers. He disappears during a year and a half, and then comes with a pull request that is changing 108 files at the same time, with breaking changes, and trying to impose to the rest these non agreed changes. I don't think it's fair, even if he is able to do good code.If you want to go this way, you should start a new module set, with different names, but leave the current ones unaltered. We are superseding this week the existing migrations on the current approach to finish them and getting them merged, as several top contributors companies like ForgeFlow, Dixmit and Tecnativa need them already.Regards._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Enric Tobella Alomar - 12:45 - 26 Mar 2025
Reference
-
The future of oca/bank-payment
Hi everyone,The oca/bank-payment repository has the essential modules to prepare and generate SEPA (and more) payment orders for credit transfer and direct debit.Today, there are important decisions to make about the future of this module.18 months ago, Alexis de Lattre, (one of) the original authors of these modules, started a huge effort to modernize these modules and improve their overall quality.He explained his approach in this PR 1174 for 16.0 [1].Naturally, that PR was not merged because it came too late in the 16.0 release cycle.Now Alexis continues this effort with a series of 18.0 pull requests, with the important addition that he proposes to replace the Payment Mode object by the now native object from Odoo.In Odoo v18, Odoo SA introduced new "Payment mode" M2O fields in the "account" module (cf this commit [6]):- on res.partner : one property field "Customer Payment Method" and one property field "Supplier Payment Method"- on invoices (account.move) : one field "Payment Method", copied from res.partner and that can be modifiedUp to Odoo v17, these "Payment mode" fields were not native ; they were added by the OCA module account_payment_partner from OCA/bank-payment.These new native "Payment mode" fields use the model account.payment.method.line (which was introduced in v15).Migrating to use these native fields makes a lot of sense to align with Odoo to avoid duplication of fields and logic.For more context, There was some discussion in the 16.0 PR [1], the 18.0 migration issue [4], as well as [5].I personally very much welcome this effort as I think the quality of Alexis' work is excellent (as usual), and this will create a solid foundation for the future.Indeed, over the many years of history of these modules, the only significant refactoring was Pedro's important work to adapt them to use Account Payment, and these modules start to show their great age.Alexis' work can be tested on runboat PR 1406 for direct debit [2] and PR 1405 for credit transfer [3]. From the preliminary tests we have done at Acsone it works fine.Of course, such work is not a traditional migration, and is difficult to review due to the importance of the changes. This will also create some additional migration work for maintainers of modules that depend on it (for instance the migration from Payment Mode to native Payment Methods will require some effort, although not difficult).On the other hand, reaching the same result by incremental improvements is going to be impossible, because as soon as a module is merged it starts to be extended, and some evolutions will not be possible in a backward-compatible way.So Akretion and Acsone propose to add migration scripts, and merge Alexis' work in 18.0 and rapidly iterate from there to review and add possible features that would have been missed in the transition. At Acsone we plan to put significant effort on this repo in the coming 3-4 months.Would there be agreement on such an approach?Best regards,-Stéphane
by Stéphane Bidoul - 11:45 - 26 Mar 2025-
Re: The future of oca/bank-payment
Hello, all colleagues!First of all, I want to greet you, and with my comment, I'm only trying to calm and soothe the moods, which are sometimes milestones that I honestly believe are of great merit. Ultimately, if we're involved in these discussions, it's because we care about our OCA Organization and contribute the best of each of us... but that doesn't mean that sometimes we don't agree, or for whatever reasons the responses and disagreements have been, we end up questioning something that doesn't convince us, or because someone has a point of view that differs from ours.That said, what we do need to safeguard is that in these discussions, we must be restrained in our comments that impact us all in some way, and because in the end, those who benefit from our public and honest disagreements that lead nowhere are the same ones who are rubbing their hands together trying to get us out of this, our common home, and move on to examples of how we don't understand each other... and that's not the case... because, I believe, sometimes our honesty and clarity in communications are the very reason we are immersed in the OCA project, and it's taking its toll on us.I would like to address this message to all colleagues in general, and especially to those involved in these recent debates. This is why I have participated in these comments. I apologize if my message is misunderstood. With the best of intentions, it only seeks to maintain the differences we deem appropriate, as is the law, but also to safeguard offensive comments and disagreements with the best possible tone and in the best possible harmony, which is how I consider all members of our OCA Organization.A hug to everyone, and I send you health and brotherhood from Andalusia (Spain).El 18/04/2025 18:52 CEST Enric Tobella Alomar <notifications@odoo-community.org> escribió:Hi Stéphane and everyone,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 (you can check on Odoos commits to see that it just a field for help on the creation of payments, nothing else). Odoo's approach is completly different in this topic and we are trying to enforce our system in something different. Also, using the word native is a way of saying that the original work is not "native". Obviously, this is not correct and you are enforcing an opinionated option as the "native". Also, we have no confirmation on this topic from Odoo (and I think they will never give an answer on this topic). For these reasons, 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. I understand that this might be rude, but you are trying to enforce a specific way of doing without taking care of PSC comments. Reviews were added on this PRs and we received no answers, we raised concerns about it and you couldn't give any compromises. In my opinion, this a rude way to act on a community environment.Personally, it seems that you are enforcing a picture where people against Alexis solution are "bad people" that are against community health. But, IMO, we delivered comments and opinions and we were ignored everytime. Even so, in the explanation of how the meeting was, it was something like: Some people opinons, but it is just opinions... Alexis thinks that his code is better, so his code is better(without proofs)... However, even Alexis confesed that he was not doing a proper work as maintainer of the tool. Sorry if some people thinks I am too direct or rude, but sometimes people need to be clear and expose their fears and concerns.Also, some PSC offered their help (Pedro and myself for example) in order to get a a middle solution, but we received no answer on that again.Maybe merging the PRs directly was not the best option, but it was clear that it was a "all or nothing" approach from Alexis side as he refused to get a middle solution no matter the comments or problems raised from the other side. IMO, merging Tecnativa's PRs was a good way to proceed, as Alexis was not giving any options to get a common ground and we have been waiting several months for this.Personally, I have been in similar situations where two people offered different solutions for the same problem and both parties tried to converge. In this case, only one of them proposed things to converge. The other one, made a fork and tried to enforce their opinion no matter what (even loosing work from other people...)Kind regards,
El vie, 18 abr 2025 a las 17:43, Stéphane Bidoul (<notifications@odoo-community.org>) escribió:Hi everyone,As we are Friday 18th, have we obtained more information from Odoo about their intentions with these fields?Pedro, I find it really rude that you closed PRs without waiting for the conclusion of this conversation.Anyway, since this is done, I conclude that the decision is taken, and it is not possible to converge for 18.I am disappointed and I see that as a kind of failure for our community that a fork has to happen, but this is the only way forward I see.The only possible solution that our tooling supports is creating modules with new names. Since these modules will contain models with identical names, we need to declare them conflicting with the existing ones in their manifests.A new repo is not strictly necessary but seems useful to reduce confusion. As I re-read the thread, there was agreement on that.I don't have a strong opinion on the name of the new repo. Alexis' proposal of bank-payment-native is better that anything else I can think of so far. Let's open the PR on repo-maintainer-conf. We can still adapt the name if a better one emerges.Could the READMEs of each repo (and if possible each addons) reference each other so users can make informed decisions and encourage future convergence?Ah, one last thing. I'm also saddened by the ad-hominem attacks in this thread. This is definitely not what we want in a thriving community. Maintaining open source projects is not easy, and if perfect maintainers exist I don't know them.To conclude, let's recognize that if convergence is not possible, exploring different approaches is also healthy, and OCA can provide room for that.Wishing you a nice weekend,-Stéphane
On Wed, Apr 16, 2025 at 11:06 AM Graeme Gellatly <notifications@odoo-community.org> wrote:Just ping me if you need review, unfortunately we get failure trying to test locally, but we are in the middle of a 450 module migration, down to last dozen or so, most ultimately depending on payment order. We have production data, freshly migrated via enterprise to do real proper testing on. Only problem we face is we can't aggregate the current merge requests. Although maybe there is a better way we can do that.merges:- origin $ODOO_VERSION# Can't merge 1439 at the moment because of this# test-requirements.txt commit:# befd64bd07aaa293026b648bc06494d6f1b466fc#- origin refs/pull/1438/head # 'account_payment_mode'#- origin refs/pull/1439/head # 'account_payment_partner'#- origin refs/pull/1440/head # 'account_payment_order'
On Wed, Apr 16, 2025 at 7:22 PM Pedro M. Baeza <notifications@odoo-community.org> wrote:I'm disappointed that both Virginie's summary and Alexis' reply appears to say "Alexis' proposal is better, but...", when I exposed clearly in the meeting and previously written on the threads that the main problems are:- The switch to account.payment.method.line is not better. It provokes a lot of work to do, user adaptation, etc, with no clear benefit.- The current proposed code starts from a fork done 2 years ago, not having all the work done meanwhile in the main branch.- It contains a lot of datamodel changes apart from the main question, which are the same problematic.And again, I'm not saying the current code quality on the XML export is the best, but that it should be worked on as a separate proposal, not trying to impose all the changes together. I even offered to help him to extract that improvement to be proposed over current OCA code, but my offering seems to not serve for anything...I'm also surprised about the washing done on Alexis' attitude, while he clearly recognized it.Anyway, I continue with the merging of the current modules that is blocking me and a lot of other good contributors, and I have already spent a lot of time on this topic.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_______________________________________________
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
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Jose Luis Baños - 09:34 - 18 Apr 2025 -
Re: The future of oca/bank-payment
And again, you are reflecting that Alexis' time is precious, while ours is simply rejected or put on background. He has spent that time because he wanted to. Since the beginning, I expressed that I think it was a bad idea, with no replies on his part, so who's having inadequate behaviors?Regards.
by Pedro M. Baeza - 07:47 - 18 Apr 2025 -
Re: The future of oca/bank-payment
> I merely pointed out a couple of things I found inadequate in this thread, and saddened me.Stéphane. I had already answered to this, as there's no inadequate behavior not having to wait more time if things are clear.> My understanding on that is that there was no alternative option that would have not cost him a huge effort on top of what he had done already. If everyone had an infinite budget and time available things would be easier :)That's not true, as all my offerings put time on my side, not him, and I have already expressed that several times. What I see inadequate is that you, Stéphane, not being part of the meeting we took, or even the conversations, seen that all that I wrote is being ignored, and given your reputation inside OCA ecosystem, throws out to me personally bad behaviors, while softening other even worst behaviors by Alexis admitted by him, like having a code that has not follow community guidelines nor collaborative minimum rules (I remind you that the proposed branch is a fork of 16.0 done 2 years ago, excluding all the community improvements meanwhile).Regards.
by Pedro M. Baeza - 07:41 - 18 Apr 2025 -
Re: The future of oca/bank-payment
Hi Enric,> Personally, it seems that you are enforcing a picture where people against Alexis solution are "bad people" that are against community healthThat is absolutely not my intent!I merely pointed out a couple of things I found inadequate in this thread, and saddened me.> Alexis was not giving any options to get a common groundMy understanding on that is that there was no alternative option that would have not cost him a huge effort on top of what he had done already. If everyone had an infinite budget and time available things would be easier :)For the rest I simply notice that no agreement was found and we now need to move forward, if possible without losing valuable contributions and contributors.So the fork is the next best solution so each approach can compete on its own merit (with of course an advantage to the incumbent and that's normal - but let's not make things harder than necessary for the new approach).Best regards,-StéphaneOn Fri, Apr 18, 2025 at 6:52 PM Enric Tobella Alomar <notifications@odoo-community.org> wrote:Hi Stéphane and everyone,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 (you can check on Odoos commits to see that it just a field for help on the creation of payments, nothing else). Odoo's approach is completly different in this topic and we are trying to enforce our system in something different. Also, using the word native is a way of saying that the original work is not "native". Obviously, this is not correct and you are enforcing an opinionated option as the "native". Also, we have no confirmation on this topic from Odoo (and I think they will never give an answer on this topic). For these reasons, 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. I understand that this might be rude, but you are trying to enforce a specific way of doing without taking care of PSC comments. Reviews were added on this PRs and we received no answers, we raised concerns about it and you couldn't give any compromises. In my opinion, this a rude way to act on a community environment.Personally, it seems that you are enforcing a picture where people against Alexis solution are "bad people" that are against community health. But, IMO, we delivered comments and opinions and we were ignored everytime. Even so, in the explanation of how the meeting was, it was something like: Some people opinons, but it is just opinions... Alexis thinks that his code is better, so his code is better(without proofs)... However, even Alexis confesed that he was not doing a proper work as maintainer of the tool. Sorry if some people thinks I am too direct or rude, but sometimes people need to be clear and expose their fears and concerns.Also, some PSC offered their help (Pedro and myself for example) in order to get a a middle solution, but we received no answer on that again.Maybe merging the PRs directly was not the best option, but it was clear that it was a "all or nothing" approach from Alexis side as he refused to get a middle solution no matter the comments or problems raised from the other side. IMO, merging Tecnativa's PRs was a good way to proceed, as Alexis was not giving any options to get a common ground and we have been waiting several months for this.Personally, I have been in similar situations where two people offered different solutions for the same problem and both parties tried to converge. In this case, only one of them proposed things to converge. The other one, made a fork and tried to enforce their opinion no matter what (even loosing work from other people...)Kind regards,El vie, 18 abr 2025 a las 17:43, Stéphane Bidoul (<notifications@odoo-community.org>) escribió:Hi everyone,As we are Friday 18th, have we obtained more information from Odoo about their intentions with these fields?Pedro, I find it really rude that you closed PRs without waiting for the conclusion of this conversation.Anyway, since this is done, I conclude that the decision is taken, and it is not possible to converge for 18.I am disappointed and I see that as a kind of failure for our community that a fork has to happen, but this is the only way forward I see.The only possible solution that our tooling supports is creating modules with new names. Since these modules will contain models with identical names, we need to declare them conflicting with the existing ones in their manifests.A new repo is not strictly necessary but seems useful to reduce confusion. As I re-read the thread, there was agreement on that.I don't have a strong opinion on the name of the new repo. Alexis' proposal of bank-payment-native is better that anything else I can think of so far. Let's open the PR on repo-maintainer-conf. We can still adapt the name if a better one emerges.Could the READMEs of each repo (and if possible each addons) reference each other so users can make informed decisions and encourage future convergence?Ah, one last thing. I'm also saddened by the ad-hominem attacks in this thread. This is definitely not what we want in a thriving community. Maintaining open source projects is not easy, and if perfect maintainers exist I don't know them.To conclude, let's recognize that if convergence is not possible, exploring different approaches is also healthy, and OCA can provide room for that.Wishing you a nice weekend,-StéphaneOn Wed, Apr 16, 2025 at 11:06 AM Graeme Gellatly <notifications@odoo-community.org> wrote:Just ping me if you need review, unfortunately we get failure trying to test locally, but we are in the middle of a 450 module migration, down to last dozen or so, most ultimately depending on payment order. We have production data, freshly migrated via enterprise to do real proper testing on. Only problem we face is we can't aggregate the current merge requests. Although maybe there is a better way we can do that.merges:- origin $ODOO_VERSION# Can't merge 1439 at the moment because of this# test-requirements.txt commit:# befd64bd07aaa293026b648bc06494d6f1b466fc#- origin refs/pull/1438/head # 'account_payment_mode'#- origin refs/pull/1439/head # 'account_payment_partner'#- origin refs/pull/1440/head # 'account_payment_order'On Wed, Apr 16, 2025 at 7:22 PM Pedro M. Baeza <notifications@odoo-community.org> wrote:I'm disappointed that both Virginie's summary and Alexis' reply appears to say "Alexis' proposal is better, but...", when I exposed clearly in the meeting and previously written on the threads that the main problems are:- The switch to account.payment.method.line is not better. It provokes a lot of work to do, user adaptation, etc, with no clear benefit.- The current proposed code starts from a fork done 2 years ago, not having all the work done meanwhile in the main branch.- It contains a lot of datamodel changes apart from the main question, which are the same problematic.And again, I'm not saying the current code quality on the XML export is the best, but that it should be worked on as a separate proposal, not trying to impose all the changes together. I even offered to help him to extract that improvement to be proposed over current OCA code, but my offering seems to not serve for anything...I'm also surprised about the washing done on Alexis' attitude, while he clearly recognized it.Anyway, I continue with the merging of the current modules that is blocking me and a lot of other good contributors, and I have already spent a lot of time on this topic.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
_______________________________________________
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_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Stéphane Bidoul - 07:21 - 18 Apr 2025 -
Re: The future of oca/bank-payment
Bravo, Enric, thanks for these words that I totally shared.Stéphane, Friday 18th was the deadline, the limit date, giving by Virginie to heard a decision on Alexis side if he wants to accept my offering of converging the good things of his proposal (like the XML export refactoring) into the current one, and put in pause (which is not the same as to reject) the switch to that fields till 19, while we get more information from Odoo what are their intentions with them, or directly see if Odoo expands their usage, but he was pretty clear that he doesn't want to converge in any case in 18 in this message, and proposing something impossible: once you split into 2, join both forks again is not going to happen. And less with a person that has proved now that has no will of wanting to converge. Or the rest follows whatever he wants to propose, or no more effort on his part. So, what I did is to follow our path. No need to wait more because nothing will change waiting till today.I reiterate again my will of putting more of my time extracting the improvements on the XML export code if you at least accept to resign on some things for 18.0 while we continue investigating, but if not, I think this is a definitive schism with a lot of consequences.Regards.
by Pedro M. Baeza - 07:16 - 18 Apr 2025
-