Archives
Contributors
-
Re: Odoo in-house contributor
Hello Procesos,
Share your contact details so that interested people can contact you directly.
In case you are considering complementing that with the support of an experienced Odoo integrator in Mexico you're welcome to drop me an email at dreis@OpenSourceIntegrators.com.
Thank you
Daniel
On 14/10/2025 00:47, procesos wrote:
Hello Community,
We are a Mexican company located in Guadalajara Mexico, we manufacture and sale working uniforms.
We are currently using Odoo v15, and wanting to upgrade to 19. We are exploring the option of having an “Odoo in-house contributor” to assist with: the version upgrade including hypercare, daily support and continuous improvement.
Is there a pool of expert candidates that I could have access to?
Thanks in advance for your guidance
Regards!
_______________________________________________
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)
by Daniel Reis - 09:16 - 14 Oct 2025 -
Odoo in-house contributor
Hello Community,
We are a Mexican company located in Guadalajara Mexico, we manufacture and sale working uniforms.
We are currently using Odoo v15, and wanting to upgrade to 19. We are exploring the option of having an “Odoo in-house contributor” to assist with: the version upgrade including hypercare, daily support and continuous improvement.
Is there a pool of expert candidates that I could have access to?
Thanks in advance for your guidance
Regards!
by procesos@bibo.com.mx - 01:45 - 14 Oct 2025 -
Re: Generate Readme.rst from md files with maintainer-tools
I think I also needed Pandoc lib locally installed when faced the very issue you are talking about.On Mon, Oct 13, 2025, 8:32 AM Stefano Consolaro <notifications@odoo-community.org> wrote:Hi everyone,
surely I'm doing something wrong but I'm not able to generate Readme.rst from readme md files, since v17.0.
I update locally the maintainer-tools repo and use the command
$>
oca-gen-addon-readme --repo-name=REPO_NAME --branch=BRANCH --addon-dir=MODULE_DIR_PATHNo error messages but no Readme.* generated.
There's a way to check/fix this?
Is it possible to update the md readme files and let something magically create the Readme.rst file in the OCA repository?
Thanks
Stefano Consolaro_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Ing. Rolando Pérez Rebollo - 07:10 - 13 Oct 2025 -
Re: Generate Readme.rst from md files with maintainer-tools
Hello Stefano,In fact, if you activate pre-commit locally, this is done automatically from fragments.Le lun. 13 oct. 2025 à 14:31, Stefano Consolaro <notifications@odoo-community.org> a écrit :Hi everyone,
surely I'm doing something wrong but I'm not able to generate Readme.rst from readme md files, since v17.0.
I update locally the maintainer-tools repo and use the command
$>
oca-gen-addon-readme --repo-name=REPO_NAME --branch=BRANCH --addon-dir=MODULE_DIR_PATHNo error messages but no Readme.* generated.
There's a way to check/fix this?
Is it possible to update the md readme files and let something magically create the Readme.rst file in the OCA repository?
Thanks
Stefano Consolaro_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Denis Roussel - 02:41 - 13 Oct 2025 -
Re: Generate Readme.rst from md files with maintainer-tools
Install pre-commit and let things happen automatically. https://github.com/OCA/maintainer-tools/wiki/Install-pre-commit
by Pedro M. Baeza - 02:36 - 13 Oct 2025 -
Generate Readme.rst from md files with maintainer-tools
Hi everyone,
surely I'm doing something wrong but I'm not able to generate Readme.rst from readme md files, since v17.0.
I update locally the maintainer-tools repo and use the command
$>
oca-gen-addon-readme --repo-name=REPO_NAME --branch=BRANCH --addon-dir=MODULE_DIR_PATHNo error messages but no Readme.* generated.
There's a way to check/fix this?
Is it possible to update the md readme files and let something magically create the Readme.rst file in the OCA repository?
Thanks
Stefano Consolarowww.mymage.it
by Stefano Consolaro - 02:30 - 13 Oct 2025 -
Please review security fix to the Python odoorpc package
Hey,I've submitted a PR to fix an issue where odoorpc logs a password when running in debug mode. It has been hanging about for 2 weeks, any chance of a review and hopefully a merge?Cheers,Andrew--
Andrew Ruthven
Chief Information Security Officer, Manager Infrastructure and Security Team
Aotearoa New Zealand's cloud provider
e andrew.ruthven@catalystcloud.nz
Level 6, Catalyst House, 150 Willis St, Wellington 6011
Confidentiality Notice: This email is intended for the named recipients only. It may contain privileged, confidential or copyright information. If you are not the named recipient, any use, reliance upon, disclosure or copying of this email or its attachments is unauthorised. If you have received this email in error, please reply via email or call +64 4 499 2267.
by "Andrew Ruthven" <andrew.ruthven@catalystcloud.nz> - 11:41 - 12 Oct 2025 -
Re: New contributor
Fantastic! Please read the contributor guidelines on odoo-community.org, and after that, open your first PR :)
11 okt. 2025 20:02:14 Jhon Alexander Romero Gonzaga <notifications@odoo-community.org>:
Hello,
My name is Jhon Romero, and I would like to contribute to OCA. My GitHub username is JhonRomero26._______________________________________________
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 - 08:46 - 11 Oct 2025 -
RE: Guidelines for LLM generated contributions
Thanks Stuart for the decent & constructive reply.
Copyright is indeed an issue industry wise, as you mentioned, with many lawsuits in place but no clear direction. This is due to how LLM models are trained and how data converted into tokens, relations, and weights and stored into multi-dimensional vector space. Certain paths may represent a piece of copyrighted artifact.
Yes, I do supervise my AI agents very strictly. Vibe coding, or whatever they call it, does not work in writing code for Odoo or any enterprise/ERP level codebase. In such complex codebase best is to treat AI agent as normal employees flow, keeping a human at last step is a must. It is crazy to see an LLM getting lazy like if it is the last hour before weekend, but it happened many times. Since those AI Agents are trained using humans data/traces, it includes good and bad behaviors and it requires some skills similar to managing normal team.
I do respect and admire OCA brand very much and I know code quality is very high in general. It is not easy to get a module into OCA repository. OCA guidelines & policies are really rail guarding the quality and the brand.
I think of LLM-OCA subject as two parts: 1) list of concerns and clarifications that would result into guidelines & policies, 2) AI tools and their usage. Even though there are many AI tools/agents but the ones that can really work in such codebase are very few.
It is my pleasure to be part of it, it is always a joy to contribute.
Sincerely,
Hussain H.
From: Stuart J Mackintosh <notifications@odoo-community.org>
Sent: Thursday, October 9, 2025 7:18 PM
To: Contributors <contributors@odoo-community.org>
Subject: Re: Guidelines for LLM generated contributionsThank you for your comments. Indeed we must not overlook the opportunities with automation however there are still issues unresolved (across industry) such as - if you use automated tools to create code, which was based on training code, and that was under AGPL, must you also apply AGPL terms? You certainly couldn't use AI as a filter to republish AGPL code as MIT for example.
Ask your AI what rights you have to the code it creates for you - it is easy tl lead it to assuring you that the code is ok, but ask explicitly if it is safe to publish under MIT licence.
In your case, it looks that you are supervising AI, but not everyone is as responsible, and abdication of responsibility is very different to delegating, and it takes quite some effort to keep up with moderating code at the speed and volume that it can be generated.
Transparency is essential, and for any OCA code, guidance & policy are prerequisite so as to not dilute the brand.
Hopefully we will get together sometime soon to consider the various points and outline the key criteria.
Best wishes,
Stuart.
On 09/10/2025 10:22, Hussain Hammad wrote:
Hi All,
I’ve seen this subject “AI Usage” opened few times in mailing list but every time I see the same problem repeated. I think the main point is very missed in this area, starting from terminology and semantic to what is used and how. I’m not touching on people technical skills here, I’m touching on experience in AI arena. Who have first-hand experience in this area to clarify things and explain, in Odoo not other technology. Who can contribute in this knowledge level-up. Who can answer those concerns. I’m not talking about visionaries, I’m talking about first-hand users AI+Odoo.
Proper decision comes from facts and understanding these facts.
I believe we need to level up OCA (Management, Members, Contributors…etc) knowledge about the subject before thinking about policy and/or adaption, otherwise decisions might harm more than benefit.
Why I’m raising this concern? We at OCA are late already in this subject. For someone like me, and many others, who breath code daily we cannot imagine not writing code for months. Believe it or not, in last 6 months I have not written a single line of code. It is more of architecting, code review, refactor, fine-tune, QC then production. AI tools are your team, managing it is on you. Bad players should not prevent us from adaption, same measures for bad player existed prior to AI time.
I’m welling to do a session about it internally for OCA, or whatever OCA sees as good start to really open this subject. A list of questions and concerns can be answered as well, coordinated by OCA.
Sincerely,
Hussain Hammad | Solutions Unity Co.
6957 Abdullah Bin Harith Street, Shati DistrictTarout 32617, Saudi Arabia
+966 56 963 4488
hussain@solutionsunity.comFrom: Joël Grand-Guillaume <notifications@odoo-community.org>
Sent: Monday, September 29, 2025 10:27 AM
To: Contributors <contributors@odoo-community.org>
Subject: Re: Guidelines for LLM generated contributions...
Whatever the case, transparency is essential, and omitting this will cause many problems such as compliance with the the new EU regulation which will activate in under 2 years.
+1 - Transparency is key in this first steps - this will maintain trust.
What's the action now - as Frederik proposed, a working group should pick this up, process the views of the community and define a policy based on consensus. This will continue to evolve so I don't think trying to nail it all down now is practical with this dynamic factored in.
+1 to have the governance working group leading this topic
Best wishes,
Stuart.
On 27/09/2025 15:07, Raphaël Valyi wrote:
Hello,
I think IA policies and risks/benefits may vary a lot depending on the use cases...
The thread was initially started about migrations. This is really a use case where IA can bring a lot of benefits with very limited risks. Indeed, recent migrations are very easy for most modules. We could have a huge benefit if we could get 1000+ modules easily migrated (with possible AI automated ports), using standard OCA tools and letting the AI adjust the tests and pre-commit considering the framework and upstream modules changes in the context window. As Graeme explained, these simple migrations usually involves no creative work nor copyright issues.
As for generating larger pieces of new modules/vibe coding, well of course there would be more things to care about, like copyrights, quality control etc...
Some projects like Qemu recently banned IA completely because they fear large pieces of contributed IA code may infringe copyrights (the LLM would kind of replicated copyrighted code without enforcing licenses) and taint the whole project. This is definitely something we should pay attention to.
For instance if the AI is trained on Odoo Enterprise code (or just even just in the context window) and new similar code is generated it could taint the OCA code. On the contrary it is also entirely possible AI could very soon replicate many EE module or ERP feature just from the UI/specs without infringing any copyright (Odoo tends to copy other apps from their UI, AI could soon do it too...)
But more importantly, there is no need for AGI nor phD level AI for AI (probably an OpenAI/Anthropic bubble) to change completely the software industry. The current level of LLMs with lowering costs is far enough to raise many concerns how code is made and more importantly how open source communities like us are organized.
As Daniel explained, AI may of course multiply toxic or spam behavior and we should hold AI users responsible for it.
But I think it is also very important to consider this: as many open source communities, the whole OCA was organized as a meritocracy where ability to create proper code and ERP knowledge was earned after many years of seniority and acknowledged as such. Despite ocasional disputes, modules authors, repo PSCs and all our OCA decision process is kind if naturally structured atop of this "traditional" coding and ERP expertise. merged code was kind of our "proof of work" in our pre-IA world.
But AI will soon bring us to a world were an LLM will be more knowledgeable than senior ERP consultants and only top coders will be able to add any value over AI generated code. Good coders with access to compute will also be able to generate or maintain orders of magnitude more code. Bad coders with bad intentions will also be able to flood the OCA with poor quality contributions and the average person will not be able/not have time to filter the good options. In this is world that is coming in just a few months, how will we be able to maintain trust and organization? IMHO this should be a top concern for the OCA.
Finally, for more than a decade, the business model behind the OCA was kind of: in traditional ERPs 70% of the cost is from consulting/customization and 30% from licenses. So some alien skilled people able to do both the code and the consulting (or small companies able to do both) would charge the 70% and use that revenue produce the ERP code free of license charges. That was working because non specialists would typically not be able simply download open source code and do their ERP project alone. So companies would somehwat hire module authors, pay the 70% consulting/customization cost and with limited parasistism, the ecosystem could somehow sustain itself.
But soon the expertise to use OCA modules will drop a lot. The AI will bring it to the user directly bypassing modules authors and contributors entirely...
How will our open source economy work in this context? Well an option I see is use AI on our side: manage order of magnitude more code and more customers for a fraction of the cost... Now, I'm almost certain if we simply reject the IA entirety, then yes, it won't take long before we are made completely obsolete.
On Sat, Sep 27, 2025, 4:47 AM Stuart J Mackintosh <notifications@odoo-community.org> wrote:
Indeed - it would be of benefit for OCA to have a position.
Best wishes,
Stuart.
On 27/09/2025 09:27, Frederik Kramer wrote:
Hi Stuart, hi all,
very valuable for decision making but I think within our community we have people thinking as strict as Gentoo, NetBSD on the matter and others that would rather adopt the stance of the Linux or Apache Foundation. So possibly the board / governance/community health WGs shall come up with a decision proposal along these lines and ask for a solid quorum in the next AGA.
Best FrederikAm 26. September 2025 08:42:39 MESZ schrieb Stuart J Mackintosh <notifications@odoo-community.org>:
Following up and to take a look at how others have dealt with these matters, I noticed Fedora released an AI policy yesterday so I have briefly summarised (perplexity) this compared with a bunch of other policies, full analysis here: https://codimd.mackintosh.me/s/ifsByh-G8#
Brief overview of policies:
- The main goal is to blend innovation with strong safeguards—using AI tools to help, but keeping people fully responsible for results.
- Most projects see transparency as crucial for maintaining trust and enabling fair review and collaboration.
- Quality control and copyright protection are prioritized: automation should not dilute standards nor introduce legal risk.
- Some policies are stricter, fully banning AI output unless human-vetted and legally certified.
- Clause implementation mostly revolves around commit messages, contributor guidelines, and reviewed workflow steps—simple, actionable, easy to follow.
This format ensures contributors know where, when, and how AI use is welcomed—and where human effort and discretion are absolutely required.Best wishes,
Stuart.
On 24/09/2025 11:01, Stuart J Mackintosh wrote:
I propose that you address these points through the mechanism proposed by Daniel - responsible use, and behavioural guidance alongside a code of conduct which can determine obligations such as disclosure of AI use; Ai is just one of a set of issues that must be addressed.
Best wishes,
Stuart.
On 24/09/2025 10:47, Graeme Gellatly wrote:
I disagree. If you are holding yourself out as a professional you should declare AI usage and the scope. Declaring AI usage is mandated for my profession, if I prepare any advice or report in a professional capacity I must declare. It is just not an option to say, oh well it is just a tool, when it really isn't, it directly created output.
It also gives valuable information to both the reviewer and ultimately the users.
It is also important from a copyright perspective. There is no copyright in a lot of AI generated work without later creative human input and even then only the human inputs are usually covered. To be fair there is also no copyright in a lot of human generated output (i.e. bug fixes and migrations) as there is no creative output, so for that kind of work AI is actually ideal. Ref https://www.copyright.gov/ai/Copyright-and-Artificial-Intelligence-Part-2-Copyrightability-Report.pdf
On Tue, Sep 23, 2025 at 8:27 PM Daniel Reis <notifications@odoo-community.org> wrote:
Hello all,
It begs the question of what is "AI generated code".
AI can assist code writing from code completion suggestions, to full design and code writing.
Or just assist with code reviews or issue resolution, without writing code.
In the end AI is just a tool.
Irresponsible use can happen with AI or any other automation tool.
What really matters is the behavior of people using these tools.
I feel that we might need a guideline regarding responsible use of automated tools, including AI, rather than specifically for AI use.
This could be fitted into a code of conduct for the community.
Thanks
DanielOn 18/09/2025 08:41, Stefan Rijnhart wrote:
Dear all,
at least one contributor is planning again to flood the OCA projects
with PRs for module migrations: https://github.com/OCA/web/issues/3285.
This volume is likely made possible through automation, with an LLM
generating the actual migration code (on top of, hopefully, a more
deterministic tool like OCA's odoo-module-migrator).
Regardless of the volume and the submitter, if the submitter has
reviewed, refined and tested the code generated by an LLM, this should
not be a problem but as a reviewer I'd like to know what I can expect.
Holger Brunn pointed out to me that in other projects, this may be
covered by a demand in the guidelines to disclose LLM usage and its
extend. For an example, see
https://github.com/ghostty-org/ghostty/pull/8289/files.
I would very much like to see such an addition to the OCA guidelines.
Additionally, I would like to suggest that the basic premise (the
generated code is indeed first self-reviewed, refined and tested) is
also made explicit, and that it is unacceptable to pass on reviewer
comments to the LLM only to copy back the LLM's response (which has
happened to me on one or two occassions).
Can I have a temperature check for your support for such an addition to
the guidelines? Or do you have other ideas or perspectives on the matter?
Cheers,
Stefan
--
Opener B.V. - Business solutions driven by open source collaboration
Stefan Rijnhart - Consultant/developer
mail:stefan@opener.amsterdam
tel: +31 (0) 6 1447 8606
web:https://opener.amsterdam
_______________________________________________
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--
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--
Dr.-Ing. Frederik Kramer
Geschäftsführer
initOS GmbH
Innungsstraße 7
21244 Buchholz i.d.N.
Phone: +49 4181 13503-12
Fax: +49 4181 13503-10
Mobil: +49 179 3901819
Email: frederik.kramer@initos.com
Web: www.initos.com
Geschäftsführung:
Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke
Sitz der Gesellschaft: Buchholz i.d.N.
Amtsgericht Tostedt, HRB 205226
Steuer-Nr: 15/200/53247
USt-IdNr.: DE815580155_______________________________________________
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_______________________________________________
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_______________________________________________
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
by Hussain Hammad - 04:26 - 11 Oct 2025 -
Re: Guidelines for LLM generated contributions
Thank you for your comments. Indeed we must not overlook the opportunities with automation however there are still issues unresolved (across industry) such as - if you use automated tools to create code, which was based on training code, and that was under AGPL, must you also apply AGPL terms? You certainly couldn't use AI as a filter to republish AGPL code as MIT for example.
Ask your AI what rights you have to the code it creates for you - it is easy tl lead it to assuring you that the code is ok, but ask explicitly if it is safe to publish under MIT licence.
In your case, it looks that you are supervising AI, but not everyone is as responsible, and abdication of responsibility is very different to delegating, and it takes quite some effort to keep up with moderating code at the speed and volume that it can be generated.
Transparency is essential, and for any OCA code, guidance & policy are prerequisite so as to not dilute the brand.
Hopefully we will get together sometime soon to consider the various points and outline the key criteria.
Best wishes,
Stuart.
On 09/10/2025 10:22, Hussain Hammad wrote:
Hi All,
I’ve seen this subject “AI Usage” opened few times in mailing list but every time I see the same problem repeated. I think the main point is very missed in this area, starting from terminology and semantic to what is used and how. I’m not touching on people technical skills here, I’m touching on experience in AI arena. Who have first-hand experience in this area to clarify things and explain, in Odoo not other technology. Who can contribute in this knowledge level-up. Who can answer those concerns. I’m not talking about visionaries, I’m talking about first-hand users AI+Odoo.
Proper decision comes from facts and understanding these facts.
I believe we need to level up OCA (Management, Members, Contributors…etc) knowledge about the subject before thinking about policy and/or adaption, otherwise decisions might harm more than benefit.
Why I’m raising this concern? We at OCA are late already in this subject. For someone like me, and many others, who breath code daily we cannot imagine not writing code for months. Believe it or not, in last 6 months I have not written a single line of code. It is more of architecting, code review, refactor, fine-tune, QC then production. AI tools are your team, managing it is on you. Bad players should not prevent us from adaption, same measures for bad player existed prior to AI time.
I’m welling to do a session about it internally for OCA, or whatever OCA sees as good start to really open this subject. A list of questions and concerns can be answered as well, coordinated by OCA.
Sincerely,
Hussain Hammad | Solutions Unity Co.
6957 Abdullah Bin Harith Street, Shati DistrictTarout 32617, Saudi Arabia
+966 56 963 4488
hussain@solutionsunity.comFrom: Joël Grand-Guillaume <notifications@odoo-community.org>
Sent: Monday, September 29, 2025 10:27 AM
To: Contributors <contributors@odoo-community.org>
Subject: Re: Guidelines for LLM generated contributions...
Whatever the case, transparency is essential, and omitting this will cause many problems such as compliance with the the new EU regulation which will activate in under 2 years.
+1 - Transparency is key in this first steps - this will maintain trust.
What's the action now - as Frederik proposed, a working group should pick this up, process the views of the community and define a policy based on consensus. This will continue to evolve so I don't think trying to nail it all down now is practical with this dynamic factored in.
+1 to have the governance working group leading this topic
Best wishes,
Stuart.
On 27/09/2025 15:07, Raphaël Valyi wrote:
Hello,
I think IA policies and risks/benefits may vary a lot depending on the use cases...
The thread was initially started about migrations. This is really a use case where IA can bring a lot of benefits with very limited risks. Indeed, recent migrations are very easy for most modules. We could have a huge benefit if we could get 1000+ modules easily migrated (with possible AI automated ports), using standard OCA tools and letting the AI adjust the tests and pre-commit considering the framework and upstream modules changes in the context window. As Graeme explained, these simple migrations usually involves no creative work nor copyright issues.
As for generating larger pieces of new modules/vibe coding, well of course there would be more things to care about, like copyrights, quality control etc...
Some projects like Qemu recently banned IA completely because they fear large pieces of contributed IA code may infringe copyrights (the LLM would kind of replicated copyrighted code without enforcing licenses) and taint the whole project. This is definitely something we should pay attention to.
For instance if the AI is trained on Odoo Enterprise code (or just even just in the context window) and new similar code is generated it could taint the OCA code. On the contrary it is also entirely possible AI could very soon replicate many EE module or ERP feature just from the UI/specs without infringing any copyright (Odoo tends to copy other apps from their UI, AI could soon do it too...)
But more importantly, there is no need for AGI nor phD level AI for AI (probably an OpenAI/Anthropic bubble) to change completely the software industry. The current level of LLMs with lowering costs is far enough to raise many concerns how code is made and more importantly how open source communities like us are organized.
As Daniel explained, AI may of course multiply toxic or spam behavior and we should hold AI users responsible for it.
But I think it is also very important to consider this: as many open source communities, the whole OCA was organized as a meritocracy where ability to create proper code and ERP knowledge was earned after many years of seniority and acknowledged as such. Despite ocasional disputes, modules authors, repo PSCs and all our OCA decision process is kind if naturally structured atop of this "traditional" coding and ERP expertise. merged code was kind of our "proof of work" in our pre-IA world.
But AI will soon bring us to a world were an LLM will be more knowledgeable than senior ERP consultants and only top coders will be able to add any value over AI generated code. Good coders with access to compute will also be able to generate or maintain orders of magnitude more code. Bad coders with bad intentions will also be able to flood the OCA with poor quality contributions and the average person will not be able/not have time to filter the good options. In this is world that is coming in just a few months, how will we be able to maintain trust and organization? IMHO this should be a top concern for the OCA.
Finally, for more than a decade, the business model behind the OCA was kind of: in traditional ERPs 70% of the cost is from consulting/customization and 30% from licenses. So some alien skilled people able to do both the code and the consulting (or small companies able to do both) would charge the 70% and use that revenue produce the ERP code free of license charges. That was working because non specialists would typically not be able simply download open source code and do their ERP project alone. So companies would somehwat hire module authors, pay the 70% consulting/customization cost and with limited parasistism, the ecosystem could somehow sustain itself.
But soon the expertise to use OCA modules will drop a lot. The AI will bring it to the user directly bypassing modules authors and contributors entirely...
How will our open source economy work in this context? Well an option I see is use AI on our side: manage order of magnitude more code and more customers for a fraction of the cost... Now, I'm almost certain if we simply reject the IA entirety, then yes, it won't take long before we are made completely obsolete.
On Sat, Sep 27, 2025, 4:47 AM Stuart J Mackintosh <notifications@odoo-community.org> wrote:
Indeed - it would be of benefit for OCA to have a position.
Best wishes,
Stuart.
On 27/09/2025 09:27, Frederik Kramer wrote:
Hi Stuart, hi all,
very valuable for decision making but I think within our community we have people thinking as strict as Gentoo, NetBSD on the matter and others that would rather adopt the stance of the Linux or Apache Foundation. So possibly the board / governance/community health WGs shall come up with a decision proposal along these lines and ask for a solid quorum in the next AGA.
Best FrederikAm 26. September 2025 08:42:39 MESZ schrieb Stuart J Mackintosh <notifications@odoo-community.org>:
Following up and to take a look at how others have dealt with these matters, I noticed Fedora released an AI policy yesterday so I have briefly summarised (perplexity) this compared with a bunch of other policies, full analysis here: https://codimd.mackintosh.me/s/ifsByh-G8#
Brief overview of policies:
- The main goal is to blend innovation with strong safeguards—using AI tools to help, but keeping people fully responsible for results.
- Most projects see transparency as crucial for maintaining trust and enabling fair review and collaboration.
- Quality control and copyright protection are prioritized: automation should not dilute standards nor introduce legal risk.
- Some policies are stricter, fully banning AI output unless human-vetted and legally certified.
- Clause implementation mostly revolves around commit messages, contributor guidelines, and reviewed workflow steps—simple, actionable, easy to follow.
This format ensures contributors know where, when, and how AI use is welcomed—and where human effort and discretion are absolutely required.Best wishes,
Stuart.
On 24/09/2025 11:01, Stuart J Mackintosh wrote:
I propose that you address these points through the mechanism proposed by Daniel - responsible use, and behavioural guidance alongside a code of conduct which can determine obligations such as disclosure of AI use; Ai is just one of a set of issues that must be addressed.
Best wishes,
Stuart.
On 24/09/2025 10:47, Graeme Gellatly wrote:
I disagree. If you are holding yourself out as a professional you should declare AI usage and the scope. Declaring AI usage is mandated for my profession, if I prepare any advice or report in a professional capacity I must declare. It is just not an option to say, oh well it is just a tool, when it really isn't, it directly created output.
It also gives valuable information to both the reviewer and ultimately the users.
It is also important from a copyright perspective. There is no copyright in a lot of AI generated work without later creative human input and even then only the human inputs are usually covered. To be fair there is also no copyright in a lot of human generated output (i.e. bug fixes and migrations) as there is no creative output, so for that kind of work AI is actually ideal. Ref https://www.copyright.gov/ai/Copyright-and-Artificial-Intelligence-Part-2-Copyrightability-Report.pdf
On Tue, Sep 23, 2025 at 8:27 PM Daniel Reis <notifications@odoo-community.org> wrote:
Hello all,
It begs the question of what is "AI generated code".
AI can assist code writing from code completion suggestions, to full design and code writing.
Or just assist with code reviews or issue resolution, without writing code.
In the end AI is just a tool.
Irresponsible use can happen with AI or any other automation tool.
What really matters is the behavior of people using these tools.
I feel that we might need a guideline regarding responsible use of automated tools, including AI, rather than specifically for AI use.
This could be fitted into a code of conduct for the community.
Thanks
Daniel
On 18/09/2025 08:41, Stefan Rijnhart wrote:
Dear all,
at least one contributor is planning again to flood the OCA projects
with PRs for module migrations: https://github.com/OCA/web/issues/3285.
This volume is likely made possible through automation, with an LLM
generating the actual migration code (on top of, hopefully, a more
deterministic tool like OCA's odoo-module-migrator).
Regardless of the volume and the submitter, if the submitter has
reviewed, refined and tested the code generated by an LLM, this should
not be a problem but as a reviewer I'd like to know what I can expect.
Holger Brunn pointed out to me that in other projects, this may be
covered by a demand in the guidelines to disclose LLM usage and its
extend. For an example, see
https://github.com/ghostty-org/ghostty/pull/8289/files.
I would very much like to see such an addition to the OCA guidelines.
Additionally, I would like to suggest that the basic premise (the
generated code is indeed first self-reviewed, refined and tested) is
also made explicit, and that it is unacceptable to pass on reviewer
comments to the LLM only to copy back the LLM's response (which has
happened to me on one or two occassions).
Can I have a temperature check for your support for such an addition to
the guidelines? Or do you have other ideas or perspectives on the matter?
Cheers,
Stefan
--
Opener B.V. - Business solutions driven by open source collaboration
Stefan Rijnhart - Consultant/developer
mail:stefan@opener.amsterdam
tel: +31 (0) 6 1447 8606
web:https://opener.amsterdam
_______________________________________________
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--
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--
Dr.-Ing. Frederik Kramer
Geschäftsführer
initOS GmbH
Innungsstraße 7
21244 Buchholz i.d.N.
Phone: +49 4181 13503-12
Fax: +49 4181 13503-10
Mobil: +49 179 3901819
Email: frederik.kramer@initos.com
Web: www.initos.com
Geschäftsführung:
Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke
Sitz der Gesellschaft: Buchholz i.d.N.
Amtsgericht Tostedt, HRB 205226
Steuer-Nr: 15/200/53247
USt-IdNr.: DE815580155_______________________________________________
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_______________________________________________
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_______________________________________________
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
by Stuart J Mackintosh - 06:16 - 9 Oct 2025 -
Re: [Odoo 19.0] Reverting the removal of Partner Title model
+1. It will be needed for sure. "partner-contact" is the best repo IMO.
From: Peter Niederlag <notifications@odoo-community.org>
Sent: 09 October 2025 3:22 PM
To: Contributors <contributors@odoo-community.org>
Subject: Re: [Odoo 19.0] Reverting the removal of Partner Title modelHi, +1 for partner-contact on OCA side. greets, Peter On 09.10.25 04:27, Aung Ko Ko Lin (QRTL) wrote: > Hello, > I am currently working on the Odoo 19.0 migration of the Japan localization module ( link [1] ), which relies on the /partner title/ feature. I noticed that the res.partner.title model has been removed in Odoo 19.0 ( https://github.com/odoo/odoo/pull/187357 [2] ). > For our localization needs, I would like to bring this model back. My proposal is: > > If there is interest from others in using this model in Odoo 19.0, I will create a new module for it under the *partner-contact* repository. > > Otherwise, I will simply add it within the Japan localization module itself. > > Please let me know if anyone else would like to make use of this model so I can decide the best approach. > > Best regards, > Aung Ko Ko Lin > > _______________________________________________ > Mailing-List: https://odoo-community.org/groups/contributors-15 [3] > Post to: mailto:contributors@odoo-community.org > Unsubscribe: https://odoo-community.org/groups?unsubscribe [4] > > > > [1] https://github.com/OCA/l10n-japan/tree/18.0/l10n_jp_partner_title_qweb > [2] https://github.com/odoo/odoo/pull/187357 > [3] https://odoo-community.org/groups/contributors-15 > [4] https://odoo-community.org/groups?unsubscribe > mit freundlichen Grüßen, Peter Niederlag -- Dipl. Ökonom Peter Niederlag Geschäftsführender Gesellschafter Lösungen für digitale Zeiten Agile DevOps, Cloud, TYPO3, Odoo und Linux Datenbetrieb Technologie UG(haftungsbeschränkt) Lipper Hellweg 146, 33605 Bielefeld Geschäftsführer: Peter Niederlag HRB 41826 Amtsgericht Bielefeld Fon 0521 / 446 958 60 Fax 0521 / 446 958 69
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Ruchir Shukla. - 12:01 - 9 Oct 2025 -
Re: [Odoo 19.0] Reverting the removal of Partner Title model
Hi, +1 for partner-contact on OCA side. greets, Peter On 09.10.25 04:27, Aung Ko Ko Lin (QRTL) wrote: > Hello, > I am currently working on the Odoo 19.0 migration of the Japan localization module ( link [1] ), which relies on the /partner title/ feature. I noticed that the res.partner.title model has been removed in Odoo 19.0 ( https://github.com/odoo/odoo/pull/187357 [2] ). > For our localization needs, I would like to bring this model back. My proposal is: > > If there is interest from others in using this model in Odoo 19.0, I will create a new module for it under the *partner-contact* repository. > > Otherwise, I will simply add it within the Japan localization module itself. > > Please let me know if anyone else would like to make use of this model so I can decide the best approach. > > Best regards, > Aung Ko Ko Lin > > _______________________________________________ > Mailing-List: https://odoo-community.org/groups/contributors-15 [3] > Post to: mailto:contributors@odoo-community.org > Unsubscribe: https://odoo-community.org/groups?unsubscribe [4] > > > > [1] https://github.com/OCA/l10n-japan/tree/18.0/l10n_jp_partner_title_qweb > [2] https://github.com/odoo/odoo/pull/187357 > [3] https://odoo-community.org/groups/contributors-15 > [4] https://odoo-community.org/groups?unsubscribe > mit freundlichen Grüßen, Peter Niederlag -- Dipl. Ökonom Peter Niederlag Geschäftsführender Gesellschafter Lösungen für digitale Zeiten Agile DevOps, Cloud, TYPO3, Odoo und Linux Datenbetrieb Technologie UG(haftungsbeschränkt) Lipper Hellweg 146, 33605 Bielefeld Geschäftsführer: Peter Niederlag HRB 41826 Amtsgericht Bielefeld Fon 0521 / 446 958 60 Fax 0521 / 446 958 69
by Peter Niederlag - 11:50 - 9 Oct 2025 -
RE: Guidelines for LLM generated contributions
Hi All,
I’ve seen this subject “AI Usage” opened few times in mailing list but every time I see the same problem repeated. I think the main point is very missed in this area, starting from terminology and semantic to what is used and how. I’m not touching on people technical skills here, I’m touching on experience in AI arena. Who have first-hand experience in this area to clarify things and explain, in Odoo not other technology. Who can contribute in this knowledge level-up. Who can answer those concerns. I’m not talking about visionaries, I’m talking about first-hand users AI+Odoo.
Proper decision comes from facts and understanding these facts.
I believe we need to level up OCA (Management, Members, Contributors…etc) knowledge about the subject before thinking about policy and/or adaption, otherwise decisions might harm more than benefit.
Why I’m raising this concern? We at OCA are late already in this subject. For someone like me, and many others, who breath code daily we cannot imagine not writing code for months. Believe it or not, in last 6 months I have not written a single line of code. It is more of architecting, code review, refactor, fine-tune, QC then production. AI tools are your team, managing it is on you. Bad players should not prevent us from adaption, same measures for bad player existed prior to AI time.
I’m welling to do a session about it internally for OCA, or whatever OCA sees as good start to really open this subject. A list of questions and concerns can be answered as well, coordinated by OCA.
Sincerely,
Hussain Hammad | Solutions Unity Co.
6957 Abdullah Bin Harith Street, Shati DistrictTarout 32617, Saudi Arabia
+966 56 963 4488
hussain@solutionsunity.comFrom: Joël Grand-Guillaume <notifications@odoo-community.org>
Sent: Monday, September 29, 2025 10:27 AM
To: Contributors <contributors@odoo-community.org>
Subject: Re: Guidelines for LLM generated contributions...
Whatever the case, transparency is essential, and omitting this will cause many problems such as compliance with the the new EU regulation which will activate in under 2 years.
+1 - Transparency is key in this first steps - this will maintain trust.
What's the action now - as Frederik proposed, a working group should pick this up, process the views of the community and define a policy based on consensus. This will continue to evolve so I don't think trying to nail it all down now is practical with this dynamic factored in.
+1 to have the governance working group leading this topic
Best wishes,
Stuart.
On 27/09/2025 15:07, Raphaël Valyi wrote:
Hello,
I think IA policies and risks/benefits may vary a lot depending on the use cases...
The thread was initially started about migrations. This is really a use case where IA can bring a lot of benefits with very limited risks. Indeed, recent migrations are very easy for most modules. We could have a huge benefit if we could get 1000+ modules easily migrated (with possible AI automated ports), using standard OCA tools and letting the AI adjust the tests and pre-commit considering the framework and upstream modules changes in the context window. As Graeme explained, these simple migrations usually involves no creative work nor copyright issues.
As for generating larger pieces of new modules/vibe coding, well of course there would be more things to care about, like copyrights, quality control etc...
Some projects like Qemu recently banned IA completely because they fear large pieces of contributed IA code may infringe copyrights (the LLM would kind of replicated copyrighted code without enforcing licenses) and taint the whole project. This is definitely something we should pay attention to.
For instance if the AI is trained on Odoo Enterprise code (or just even just in the context window) and new similar code is generated it could taint the OCA code. On the contrary it is also entirely possible AI could very soon replicate many EE module or ERP feature just from the UI/specs without infringing any copyright (Odoo tends to copy other apps from their UI, AI could soon do it too...)
But more importantly, there is no need for AGI nor phD level AI for AI (probably an OpenAI/Anthropic bubble) to change completely the software industry. The current level of LLMs with lowering costs is far enough to raise many concerns how code is made and more importantly how open source communities like us are organized.
As Daniel explained, AI may of course multiply toxic or spam behavior and we should hold AI users responsible for it.
But I think it is also very important to consider this: as many open source communities, the whole OCA was organized as a meritocracy where ability to create proper code and ERP knowledge was earned after many years of seniority and acknowledged as such. Despite ocasional disputes, modules authors, repo PSCs and all our OCA decision process is kind if naturally structured atop of this "traditional" coding and ERP expertise. merged code was kind of our "proof of work" in our pre-IA world.
But AI will soon bring us to a world were an LLM will be more knowledgeable than senior ERP consultants and only top coders will be able to add any value over AI generated code. Good coders with access to compute will also be able to generate or maintain orders of magnitude more code. Bad coders with bad intentions will also be able to flood the OCA with poor quality contributions and the average person will not be able/not have time to filter the good options. In this is world that is coming in just a few months, how will we be able to maintain trust and organization? IMHO this should be a top concern for the OCA.
Finally, for more than a decade, the business model behind the OCA was kind of: in traditional ERPs 70% of the cost is from consulting/customization and 30% from licenses. So some alien skilled people able to do both the code and the consulting (or small companies able to do both) would charge the 70% and use that revenue produce the ERP code free of license charges. That was working because non specialists would typically not be able simply download open source code and do their ERP project alone. So companies would somehwat hire module authors, pay the 70% consulting/customization cost and with limited parasistism, the ecosystem could somehow sustain itself.
But soon the expertise to use OCA modules will drop a lot. The AI will bring it to the user directly bypassing modules authors and contributors entirely...
How will our open source economy work in this context? Well an option I see is use AI on our side: manage order of magnitude more code and more customers for a fraction of the cost... Now, I'm almost certain if we simply reject the IA entirety, then yes, it won't take long before we are made completely obsolete.
On Sat, Sep 27, 2025, 4:47 AM Stuart J Mackintosh <notifications@odoo-community.org> wrote:
Indeed - it would be of benefit for OCA to have a position.
Best wishes,
Stuart.
On 27/09/2025 09:27, Frederik Kramer wrote:
Hi Stuart, hi all,
very valuable for decision making but I think within our community we have people thinking as strict as Gentoo, NetBSD on the matter and others that would rather adopt the stance of the Linux or Apache Foundation. So possibly the board / governance/community health WGs shall come up with a decision proposal along these lines and ask for a solid quorum in the next AGA.
Best FrederikAm 26. September 2025 08:42:39 MESZ schrieb Stuart J Mackintosh <notifications@odoo-community.org>:
Following up and to take a look at how others have dealt with these matters, I noticed Fedora released an AI policy yesterday so I have briefly summarised (perplexity) this compared with a bunch of other policies, full analysis here: https://codimd.mackintosh.me/s/ifsByh-G8#
Brief overview of policies:
- The main goal is to blend innovation with strong safeguards—using AI tools to help, but keeping people fully responsible for results.
- Most projects see transparency as crucial for maintaining trust and enabling fair review and collaboration.
- Quality control and copyright protection are prioritized: automation should not dilute standards nor introduce legal risk.
- Some policies are stricter, fully banning AI output unless human-vetted and legally certified.
- Clause implementation mostly revolves around commit messages, contributor guidelines, and reviewed workflow steps—simple, actionable, easy to follow.
This format ensures contributors know where, when, and how AI use is welcomed—and where human effort and discretion are absolutely required.Best wishes,
Stuart.
On 24/09/2025 11:01, Stuart J Mackintosh wrote:
I propose that you address these points through the mechanism proposed by Daniel - responsible use, and behavioural guidance alongside a code of conduct which can determine obligations such as disclosure of AI use; Ai is just one of a set of issues that must be addressed.
Best wishes,
Stuart.
On 24/09/2025 10:47, Graeme Gellatly wrote:
I disagree. If you are holding yourself out as a professional you should declare AI usage and the scope. Declaring AI usage is mandated for my profession, if I prepare any advice or report in a professional capacity I must declare. It is just not an option to say, oh well it is just a tool, when it really isn't, it directly created output.
It also gives valuable information to both the reviewer and ultimately the users.
It is also important from a copyright perspective. There is no copyright in a lot of AI generated work without later creative human input and even then only the human inputs are usually covered. To be fair there is also no copyright in a lot of human generated output (i.e. bug fixes and migrations) as there is no creative output, so for that kind of work AI is actually ideal. Ref https://www.copyright.gov/ai/Copyright-and-Artificial-Intelligence-Part-2-Copyrightability-Report.pdf
On Tue, Sep 23, 2025 at 8:27 PM Daniel Reis <notifications@odoo-community.org> wrote:
Hello all,
It begs the question of what is "AI generated code".
AI can assist code writing from code completion suggestions, to full design and code writing.
Or just assist with code reviews or issue resolution, without writing code.
In the end AI is just a tool.
Irresponsible use can happen with AI or any other automation tool.
What really matters is the behavior of people using these tools.
I feel that we might need a guideline regarding responsible use of automated tools, including AI, rather than specifically for AI use.
This could be fitted into a code of conduct for the community.
Thanks
Daniel
On 18/09/2025 08:41, Stefan Rijnhart wrote:
Dear all,
at least one contributor is planning again to flood the OCA projects
with PRs for module migrations: https://github.com/OCA/web/issues/3285.
This volume is likely made possible through automation, with an LLM
generating the actual migration code (on top of, hopefully, a more
deterministic tool like OCA's odoo-module-migrator).
Regardless of the volume and the submitter, if the submitter has
reviewed, refined and tested the code generated by an LLM, this should
not be a problem but as a reviewer I'd like to know what I can expect.
Holger Brunn pointed out to me that in other projects, this may be
covered by a demand in the guidelines to disclose LLM usage and its
extend. For an example, see
https://github.com/ghostty-org/ghostty/pull/8289/files.
I would very much like to see such an addition to the OCA guidelines.
Additionally, I would like to suggest that the basic premise (the
generated code is indeed first self-reviewed, refined and tested) is
also made explicit, and that it is unacceptable to pass on reviewer
comments to the LLM only to copy back the LLM's response (which has
happened to me on one or two occassions).
Can I have a temperature check for your support for such an addition to
the guidelines? Or do you have other ideas or perspectives on the matter?
Cheers,
Stefan
--
Opener B.V. - Business solutions driven by open source collaboration
Stefan Rijnhart - Consultant/developer
mail:stefan@opener.amsterdam
tel: +31 (0) 6 1447 8606
web:https://opener.amsterdam
_______________________________________________
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--
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
IM: xmpp: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--
Dr.-Ing. Frederik Kramer
Geschäftsführer
initOS GmbH
Innungsstraße 7
21244 Buchholz i.d.N.
Phone: +49 4181 13503-12
Fax: +49 4181 13503-10
Mobil: +49 179 3901819
Email: frederik.kramer@initos.com
Web: www.initos.com
Geschäftsführung:
Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke
Sitz der Gesellschaft: Buchholz i.d.N.
Amtsgericht Tostedt, HRB 205226
Steuer-Nr: 15/200/53247
USt-IdNr.: DE815580155_______________________________________________
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
IM: xmpp: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_______________________________________________
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
IM: xmpp: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_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Hussain Hammad - 10:21 - 9 Oct 2025 -
Re: [Odoo 19.0] Reverting the removal of Partner Title model
HelloWe have 2 approaches concerning partner titles at OCA :andPlease input your povBest regards--------------------------------
Cyril VINH-TUNG
INVITU
Computer & Network Engineering
BP 32 - 98713 Papeete - French Polynesia
Tél: +689 40 46 11 99
contact@invitu.com
www.invitu.comLe mer. 8 oct. 2025, 16:27, Aung Ko Ko Lin (QRTL) <notifications@odoo-community.org> a écrit :Hello,
I am currently working on the Odoo 19.0 migration of the Japan localization module (link), which relies on the partner title feature. I noticed that the
res.partner.titlemodel has been removed in Odoo 19.0 (https://github.com/odoo/odoo/pull/187357).For our localization needs, I would like to bring this model back. My proposal is:
-
If there is interest from others in using this model in Odoo 19.0, I will create a new module for it under the partner-contact repository.
-
Otherwise, I will simply add it within the Japan localization module itself.
Please let me know if anyone else would like to make use of this model so I can decide the best approach.
Best regards,
Aung Ko Ko Lin
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Cyril VINH-TUNG - 09:40 - 9 Oct 2025 -
-
Re: [Odoo 19.0] Reverting the removal of Partner Title model
partner-contact. It has more sense there. I am sure that other people will need that :DEl jue, 9 oct 2025 a las 7:51, Daniel Reis (<notifications@odoo-community.org>) escribió:I think it should go in oca/partner-contact.
--Daniel
From: Aung Ko Ko Lin (QRTL) <notifications@odoo-community.org>
Sent: Thursday, October 9, 2025 3:27:16 AM
To: Contributors <contributors@odoo-community.org>
Subject: [Odoo 19.0] Reverting the removal of Partner Title modelHello,
I am currently working on the Odoo 19.0 migration of the Japan localization module (link), which relies on the partner title feature. I noticed that the
res.partner.titlemodel has been removed in Odoo 19.0 (https://github.com/odoo/odoo/pull/187357).For our localization needs, I would like to bring this model back. My proposal is:
-
If there is interest from others in using this model in Odoo 19.0, I will create a new module for it under the partner-contact repository.
-
Otherwise, I will simply add it within the Japan localization module itself.
Please let me know if anyone else would like to make use of this model so I can decide the best approach.
Best regards,
Aung Ko Ko Lin
_______________________________________________
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 - 08:11 - 9 Oct 2025 -
-
Re: [Odoo 19.0] Reverting the removal of Partner Title model
I think so as well, especially because the change of Odoo doesn't seem to be explicitely justfied anywhere in the PR.
I am quite sure that this res.partner.title model is useful and after all used beyond the Japanase scope.
Best Frederik
Am 09.10.25 um 07:51 schrieb Daniel Reis:
I think it should go in oca/partner-contact.
--Daniel
From: Aung Ko Ko Lin (QRTL) <notifications@odoo-community.org>
Sent: Thursday, October 9, 2025 3:27:16 AM
To: Contributors <contributors@odoo-community.org>
Subject: [Odoo 19.0] Reverting the removal of Partner Title modelHello,
I am currently working on the Odoo 19.0 migration of the Japan localization module (link), which relies on the partner title feature. I noticed that the
res.partner.titlemodel has been removed in Odoo 19.0 (https://github.com/odoo/odoo/pull/187357).For our localization needs, I would like to bring this model back. My proposal is:
-
If there is interest from others in using this model in Odoo 19.0, I will create a new module for it under the partner-contact repository.
-
Otherwise, I will simply add it within the Japan localization module itself.
Please let me know if anyone else would like to make use of this model so I can decide the best approach.
Best regards,
Aung Ko Ko Lin
_______________________________________________
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
-- Dr.-Ing. Frederik Kramer Geschäftsführer initOS GmbH Innungsstraße 7 21244 Buchholz i.d.N. Tel: +49 (0) 4181 13503 12 Fax: +49 (0) 4181 13503 10 Mobil: +49 (0) 179 3901819 Email: frederik.kramer@initos.com Internet: www.initos.com Geschäftsführung: Dr.-Ing. Frederik Kramer & Dipl.-Ing. (FH) Torsten Francke Sitz der Gesellschaft: Buchholz i.d.N. Amtsgericht Tostedt, HRB 205226 USt-IdNr.: DE815580155 Steuer-Nr: 15/200/53247
by Frederik Kramer - 08:11 - 9 Oct 2025 -
-
Re: [Odoo 19.0] Reverting the removal of Partner Title model
I think it should go in oca/partner-contact.
--Daniel
From: Aung Ko Ko Lin (QRTL) <notifications@odoo-community.org>
Sent: Thursday, October 9, 2025 3:27:16 AM
To: Contributors <contributors@odoo-community.org>
Subject: [Odoo 19.0] Reverting the removal of Partner Title modelHello,
I am currently working on the Odoo 19.0 migration of the Japan localization module (link), which relies on the partner title feature. I noticed that the
res.partner.titlemodel has been removed in Odoo 19.0 (https://github.com/odoo/odoo/pull/187357).For our localization needs, I would like to bring this model back. My proposal is:
-
If there is interest from others in using this model in Odoo 19.0, I will create a new module for it under the partner-contact repository.
-
Otherwise, I will simply add it within the Japan localization module itself.
Please let me know if anyone else would like to make use of this model so I can decide the best approach.
Best regards,
Aung Ko Ko Lin
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Daniel Reis - 07:51 - 9 Oct 2025 -
-
[Odoo 19.0] Reverting the removal of Partner Title model
Hello,
I am currently working on the Odoo 19.0 migration of the Japan localization module (link), which relies on the partner title feature. I noticed that the
res.partner.titlemodel has been removed in Odoo 19.0 (https://github.com/odoo/odoo/pull/187357).For our localization needs, I would like to bring this model back. My proposal is:
-
If there is interest from others in using this model in Odoo 19.0, I will create a new module for it under the partner-contact repository.
-
Otherwise, I will simply add it within the Japan localization module itself.
Please let me know if anyone else would like to make use of this model so I can decide the best approach.
Best regards,
Aung Ko Ko Lin
by Aung Ko Ko Lin - 04:25 - 9 Oct 2025 -
