Archives
Contributors
-
Sale workflow repository v16
Dear contributors,For weeks, the v16 builds on sale-workflow repository have been broken due to the incompatibility with current sale_triple_discount module implementation and the depending version of account_invoice_triple_discount (refactoring has been done there and not yet on sale side).I've fixed the builds pinning the account_invoice_triple_discount dependency before refactor.You can now rebase your pending PR's and let's go forward.Thanks for your patience.
by Denis Roussel - 05:56 - 28 Apr 2025 -
Re: AW: BI and reporting tools
Hi all,I have tested the metabase on my laptop. It does the job but in the context of an odoo database with a lot of tables and data,it seems it consumes a lot of memory (really really a lot).Probably there are in this video more innovative ways to build an BI tools.Yes BI requires it to be managed with traceability. Changes should be reverted if necessary.Personally I have succinctly used odoo shiny spreadsheets with a lot of frustrations :-( . Is there somebody who seriously uses it ?I plan to invest in solutions from this video : https://evidence.dev markdown + sql sounds great.Marimo could also be a solution in future iterations.I'm interested in your feedback in this field. Thanksmy 2 ctsRegardsLe jeu. 17 avr. 2025 à 16:12, Joel Patrick <notifications@odoo-community.org> a écrit :I am interested in using BI to help with decision-making on in-process inventory. There are industrial processes where materials are kept in process for a period of time to all maturation (winemaking, food processing, crystal growing, and many other things. Sometimes you can use a very deterministic recipe, but more often than not, you have a range of outcomes to plan for. I would like to use the Odoo data record (registered in Mfg Orders) to build a body of knowledge linked to history by product and product family to help users manage rough cut planning and refine recipes. Ultimately, I would like to use the past MO data for analysis and as a reference in real time. This was a hot topic for leveraging SAP HANA, but I left the SAP ecosystem before I could see that in practice (to the extent that something happened with the idea.)I like the idea of putting the datasets in Postgres since most of my implementations are quite small-scale, and I am thinking it would be easier to reuse a focused decision-support dataset via an Odoo custom model.Any thoughts?On Thu, Apr 17, 2025 at 5:38 AM Victor Champonnois <notifications@odoo-community.org> wrote:Thank you for your replies, I will have a look at Metabase.
Thank you also for the tips about foreign data wrapper and Metabase models. Real time reporting is indeed an important feature.
Have a nice day,
Victor Champonnois - Coop IT Easy
On 16/04/25 10:47, David Brühlmeier wrote:
Hi Victor,
We are using Metabase (self-hosted) and are very happy with it so far. The main advantage IMHO is the possibility to connect data from Odoo with data from other data sources. The main disadvantage is the potential complexity of the Odoo data model. To address this, we are providing Models in Metabase for all the main business objects or our end users.
In terms of architecture we have decided to use Metabase without an ETL layer. Metabase connects only to one database (because it's currently not possible to make joins in Metabase from different databases). This database is a dedicated Postgres instance, which uses FDW (Foreign Data Wrapper) to connect to the source databases, such as Odoo. This approach has the advantage of realtime reporting and also reducing complexity because we don't need an ETL process. In terms of performance, it's good enough so far. Should we run into issues, we might add a read-replica as a secondary database for our source applications.
Hope this helps!Dave
Von: Victor Champonnois <notifications@odoo-community.org>
Gesendet: Mittwoch, 16. April 2025 10:32
An: Contributors <contributors@odoo-community.org>
Betreff: BI and reporting toolsHi,
I am researching different ways to do BI (business intelligence) and reporting with Odoo.
I am wondering whether it's worth it to invest on an external BI tool connected to the Odoo database.
On the community version I have the impression that the standard BI tools (standard pivot and graphs reports in Odoo) are sometimes limited in terms of performance (it's slow for wide and long pivot tables), data visualization (standard charts are not very useful) and flexibility (hard to make computations).
I know of the bi_view_editor and bi_sql_editor modules. Both are very useful and greatly extends the standard reports. But the limits listed above remains. But it seems it's hard to use it as is, in my case I always have to export manually the tables to build the table or chart I want with excel.
I also know of the spreadsheet and dashboard modules, although I don't have a great experience with it. Maybe it provides the lacking flexibility mentioned above ?
The last option is to connect a BI tool (Tableau, PowerBI, Apache superset, Metabase...) to the database. The main advantage is to connect it to other sources of data. But I am wondering if it's still worth it even connected only to the Odoo database.
Do you use an external BI tools ? If yes, which one seems to work well with Odoo (and preferably open source) ?
If no, how do you deal with BI and reporting for your clients ? Are you also confronted to performance issues, lack of flexibility and poor library of charts ?
Thank you for your inputs !
-- Victor Champonnois - Coop IT Easy_______________________________________________
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 David BEAL - 01:20 - 28 Apr 2025 -
Re: [Question] Preserve breadcrumb after page reload or reposition chatter dynamically
Hello Tris,
Thank you very much for your quick reply!
I will take a closer look at the PR you mentioned.
Best regards,
Nazaire ADJAKOUNLe lun. 28 avr. 2025 à 10:53, Tris Doan <notifications@odoo-community.org> a écrit :On Mon, Apr 28, 2025 at 4:27 PM Dayo Sikiton Nazaire ADJAKOUN <notifications@odoo-community.org> wrote:Hello everyone,
While working on an Odoo 17 project, I inherited the web_chatter_position module to add a button on form views that allows users to change the position of the chatter (either at the side or at the bottom of the form).
Currently, to make the position change effective, the button triggers a page reload, which unfortunately causes the breadcrumb to be lost.
My goal would be either:
• to preserve the breadcrumb after a reload (or restore it properly),
• or even better, to apply the chatter position change without reloading the page to keep a smooth UX.
I explored several approaches (dynamic JS manipulation, extending FormRenderer, etc.), but I haven’t found a satisfactory solution yet.
Would anyone know:
• of an existing community module that handles this use case?
• or of a clean technique to dynamically reposition the chatter without forcing a page reload?
Thank you very much in advance for your insights and suggestions!
Best regards,
Nazaire ADJAKOUN
ZENPILOTE_______________________________________________
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 Nazaire ADJAKOUN - 12:55 - 28 Apr 2025 -
Re: [Question] Preserve breadcrumb after page reload or reposition chatter dynamically
On Mon, Apr 28, 2025 at 4:27 PM Dayo Sikiton Nazaire ADJAKOUN <notifications@odoo-community.org> wrote:Hello everyone,
While working on an Odoo 17 project, I inherited the web_chatter_position module to add a button on form views that allows users to change the position of the chatter (either at the side or at the bottom of the form).
Currently, to make the position change effective, the button triggers a page reload, which unfortunately causes the breadcrumb to be lost.
My goal would be either:
• to preserve the breadcrumb after a reload (or restore it properly),
• or even better, to apply the chatter position change without reloading the page to keep a smooth UX.
I explored several approaches (dynamic JS manipulation, extending FormRenderer, etc.), but I haven’t found a satisfactory solution yet.
Would anyone know:
• of an existing community module that handles this use case?
• or of a clean technique to dynamically reposition the chatter without forcing a page reload?
Thank you very much in advance for your insights and suggestions!
Best regards,
Nazaire ADJAKOUN
ZENPILOTE_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by doanminhtri8183 - 11:51 - 28 Apr 2025 -
[Question] Preserve breadcrumb after page reload or reposition chatter dynamically
Hello everyone,
While working on an Odoo 17 project, I inherited the web_chatter_position module to add a button on form views that allows users to change the position of the chatter (either at the side or at the bottom of the form).
Currently, to make the position change effective, the button triggers a page reload, which unfortunately causes the breadcrumb to be lost.
My goal would be either:
• to preserve the breadcrumb after a reload (or restore it properly),
• or even better, to apply the chatter position change without reloading the page to keep a smooth UX.
I explored several approaches (dynamic JS manipulation, extending FormRenderer, etc.), but I haven’t found a satisfactory solution yet.
Would anyone know:
• of an existing community module that handles this use case?
• or of a clean technique to dynamically reposition the chatter without forcing a page reload?
Thank you very much in advance for your insights and suggestions!
Best regards,
Nazaire ADJAKOUN
ZENPILOTE
by Nazaire ADJAKOUN - 11:26 - 28 Apr 2025 -
Re: Odoo Module Dependency Visualisation
Hi,
I did something much simpler - took a copy of https://github.com/OCA/hr/tree/13.0/hr_org_chart_overview but the org units with modules. However was pretty simple not taking care of loops and such. Your look nice.
Best regards
Radovan Skolnik
On piatok 25. apríla 2025 16:33:42 CEST Janik von Rotz wrote:
> Hi everybody,
> I wanted to visualize the dependencies
> of Odoo modules in a folder and build a script that produces a
> vis.js powered html:
> https://github.com/Mint-System/Odoo-Build/blob/main/bin/odoo-module-dependen
> cies [1] Here is the Odoo 16.0 planet 🙂
>
>
>
> Now I am thinking about adding more
> features such as search and coloring the type of modules.
> However, I would like to know if
> somebody in the OCA community already did something similar.
> Would be nice to hear from you :)
>
> Cheers, Janik
>
> --
> Suggest a meeting: https://apmt.day/janikvonrotz/999120f2/ [2]
> We are hiring: https://www.mint-system.ch/jobs [3]
> CTO Mint System GmbH
> Tel: +41 44 244 7222
>
> _______________________________________________
> Mailing-List: https://odoo-community.org/groups/contributors-15 [4]
> Post to: mailto:contributors@odoo-community.org
> Unsubscribe: https://odoo-community.org/groups?unsubscribe [5]
>
>
>
> [1]
> https://github.com/Mint-System/Odoo-Build/blob/main/bin/odoo-module-depende
> ncies [2] https://apmt.day/janikvonrotz/999120f2/
> [3] https://www.mint-system.ch/jobs
> [4] https://odoo-community.org/groups/contributors-15
> [5] https://odoo-community.org/groups?unsubscribe
by Radovan Skolnik - 06:41 - 25 Apr 2025 -
Odoo Module Dependency Visualisation
Hi everybody,
I wanted to visualize the dependencies of Odoo modules in a folder and build a script that produces a vis.js powered html: https://github.com/Mint-System/Odoo-Build/blob/main/bin/odoo-module-dependencies
Here is the Odoo 16.0 planet 🙂
Now I am thinking about adding more features such as search and coloring the type of modules.
However, I would like to know if somebody in the OCA community already did something similar.
Would be nice to hear from you :)
Cheers, Janik
-- Suggest a meeting: https://apmt.day/janikvonrotz/999120f2/ We are hiring: https://www.mint-system.ch/jobs CTO Mint System GmbH Tel: +41 44 244 7222
by Janik von Rotz - 04:31 - 25 Apr 2025 -
newbie question about (weird) events module functionality needed
Hi everyone,
I think it's a simple question, but I'm not sure.
I am looking for something similar to events to manage courses. Let me explain:
- The ability to define a course as spanning several parts of a day. Say day-1-morning, day-2-afternoon, day-3-afternoon, day-4-morning
- And A different training can be held on day-1-afternoon,
day-2-morning, day-3-morning, day-4-afternoon
- Preferably see the planning of trainingcourses in the calendar
so I know what I have to do on day X.
- The usual tidbits: defining a course, enabling people to
register, invoicing the trainingcourse.
Does anybody know of a module that does this?
Just a short pointer would really help me out.
Thanks in advance.
Jeroen Baten
-- Jeroen Baten | EMAIL : JBATEN@I2RS.NL ____ _ __ | web : www.i2rs.nl | )|_)(_ | tel : +31 (0)648519096 _|_/_| \__) | Frisolaan 16, 4101 JK, Culemborg, the Netherlands
by Jeroen Baten - 03:46 - 25 Apr 2025 -
Request for Community Input: Price List Assignment Behavior Change Between v13 and v17
Dear OCA Contributors, I hope this message finds you well. I’m writing to kindly draw your attention to an open issue in the [sale-workflow repository](https://github.com/OCA/sale-workflow/issues/3690) regarding a change in price list assignment behavior between Odoo v13 and v17. This issue affects clients who’ve migrated and rely on explicit partner-level price list configurations. Key Points for Awareness: - Behavior Change: The system now prioritizes Order Type-assigned price lists over direct partner settings (reversing v13 logic). - Impact: May lead to unintended pricing scenarios for migrated databases. - Documentation Gap: No migration notes or prior discussions were found about this change. How You Can Help: 1. Share Insights: If you’ve encountered this or know the rationale behind the change, please comment on the [GitHub issue thread](https://github.com/OCA/sale-workflow/issues/3690). 2. Reproduce: Verify the behavior in your environments (Runbot or local instances). 3. Suggest Solutions: Propose paths forward (e.g., restore v13 logic, add configurable priority). Why GitHub? To keep the discussion centralized and actionable, we’d appreciate all feedback directly on the issue thread. This ensures transparency and easier tracking for future reference. Thank you for your time and expertise! Let’s collaborate to find the best resolution for the community. Best regards, \rrebollo Binhex
by Ing. Rolando Pérez Rebollo - 03:31 - 25 Apr 2025 -
Re: odoo/odoo 16.0 missing demo data Heisenbug alert!
In fact Antonio just told me the next oca-ci image daily build will be in a few hours, so the CI in a few 16.0 (like OCA/l10n-brazil) might still be broken meanwhile...On Tue, Apr 22, 2025 at 12:42 PM Virginie Dewulf <virginie@odoo-community.org> wrote:Good news.Thanks for sharing these bad then good news and for having spotted the issue together with Antonio Neto, Raphaël!Enjoy the rest of the week,Le mar. 22 avr. 2025 à 14:33, Raphaël Valyi <notifications@odoo-community.org> a écrit :FYI they reverted the bad commit today, si the regression is fixed: https://github.com/odoo/odoo/commit/a7201a9684c2f4724fe6b8560d69a1e21353f7efOn Sun, Apr 20, 2025 at 8:17 PM Raphaël Valyi <notifications@odoo-community.org> wrote:Hello community,First please let's not forget we are fighting against bigger issues than just the 1% of OCA modules that depend on account_payment_order...And it happens that Odoo just broke the quiet Easter Peace and dropped one of their secret heisenbugs in the odoo/ooo repo, in the 16.0 branch (only in this branch). Since this change Friday https://github.com/odoo/odoo/pull/205695/files, modules with no dependencies or with auto_install: True will no longer get their beloved demo data installed!Their demo data might be simply missing or it might easily break the CI if dependent modules depend on these demo data (for their own demo data for instance)... I guess the laser eyes from Julien00859 just miss the issue...Proposed fix: https://github.com/odoo/odoo/pull/206767You might get the impression we are not doing much here in Brazil, but the bug and the fix has been discovered by Antonio Neto from Engenere here who would not be there if we didn't have this crazy Brazilian localization around... So kudos to him.--Raphaël ValyiFounder and consultant_______________________________________________
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_______________________________________________
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
--Raphaël ValyiFounder and consultant
by Raphaël Akretion - 04:21 - 22 Apr 2025 -
Re: odoo/odoo 16.0 missing demo data Heisenbug alert!
Good news.Thanks for sharing these bad then good news and for having spotted the issue together with Antonio Neto, Raphaël!Enjoy the rest of the week,Le mar. 22 avr. 2025 à 14:33, Raphaël Valyi <notifications@odoo-community.org> a écrit :FYI they reverted the bad commit today, si the regression is fixed: https://github.com/odoo/odoo/commit/a7201a9684c2f4724fe6b8560d69a1e21353f7efOn Sun, Apr 20, 2025 at 8:17 PM Raphaël Valyi <notifications@odoo-community.org> wrote:Hello community,First please let's not forget we are fighting against bigger issues than just the 1% of OCA modules that depend on account_payment_order...And it happens that Odoo just broke the quiet Easter Peace and dropped one of their secret heisenbugs in the odoo/ooo repo, in the 16.0 branch (only in this branch). Since this change Friday https://github.com/odoo/odoo/pull/205695/files, modules with no dependencies or with auto_install: True will no longer get their beloved demo data installed!Their demo data might be simply missing or it might easily break the CI if dependent modules depend on these demo data (for their own demo data for instance)... I guess the laser eyes from Julien00859 just miss the issue...Proposed fix: https://github.com/odoo/odoo/pull/206767You might get the impression we are not doing much here in Brazil, but the bug and the fix has been discovered by Antonio Neto from Engenere here who would not be there if we didn't have this crazy Brazilian localization around... So kudos to him.--Raphaël ValyiFounder and consultant_______________________________________________
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_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Virginie Dewulf - 02:41 - 22 Apr 2025 -
Re: odoo/odoo 16.0 missing demo data Heisenbug alert!
FYI they reverted the bad commit today, si the regression is fixed: https://github.com/odoo/odoo/commit/a7201a9684c2f4724fe6b8560d69a1e21353f7efOn Sun, Apr 20, 2025 at 8:17 PM Raphaël Valyi <notifications@odoo-community.org> wrote:Hello community,First please let's not forget we are fighting against bigger issues than just the 1% of OCA modules that depend on account_payment_order...And it happens that Odoo just broke the quiet Easter Peace and dropped one of their secret heisenbugs in the odoo/ooo repo, in the 16.0 branch (only in this branch). Since this change Friday https://github.com/odoo/odoo/pull/205695/files, modules with no dependencies or with auto_install: True will no longer get their beloved demo data installed!Their demo data might be simply missing or it might easily break the CI if dependent modules depend on these demo data (for their own demo data for instance)... I guess the laser eyes from Julien00859 just miss the issue...Proposed fix: https://github.com/odoo/odoo/pull/206767You might get the impression we are not doing much here in Brazil, but the bug and the fix has been discovered by Antonio Neto from Engenere here who would not be there if we didn't have this crazy Brazilian localization around... So kudos to him.--Raphaël ValyiFounder and consultant_______________________________________________
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 - 02:31 - 22 Apr 2025 -
odoo/odoo 16.0 missing demo data Heisenbug alert!
Hello community,First please let's not forget we are fighting against bigger issues than just the 1% of OCA modules that depend on account_payment_order...And it happens that Odoo just broke the quiet Easter Peace and dropped one of their secret heisenbugs in the odoo/ooo repo, in the 16.0 branch (only in this branch). Since this change Friday https://github.com/odoo/odoo/pull/205695/files, modules with no dependencies or with auto_install: True will no longer get their beloved demo data installed!Their demo data might be simply missing or it might easily break the CI if dependent modules depend on these demo data (for their own demo data for instance)... I guess the laser eyes from Julien00859 just miss the issue...Proposed fix: https://github.com/odoo/odoo/pull/206767You might get the impression we are not doing much here in Brazil, but the bug and the fix has been discovered by Antonio Neto from Engenere here who would not be there if we didn't have this crazy Brazilian localization around... So kudos to him.--Raphaël ValyiFounder and consultant
by Raphaël Akretion - 10:16 - 20 Apr 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 -
Re: The future of oca/bank-payment
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
by Enric Tobella Alomar - 06:50 - 18 Apr 2025 -
Re: The future of oca/bank-payment
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
by Stéphane Bidoul - 05:42 - 18 Apr 2025
