Skip to Content
  2. Mailing Lists
  3. Contributors

Archives

Contributors

  • OCA Apps on Odoo App Store: status (for v18 and all versions)
    Hello everyone,

    The majority of the OCA modules are available on the official Odoo App Store. 

    However, the way the App Store is built might bring issues for certain of our modules to be published (for example when a module moves from one OCA repo to another).

    As the process of publishing the OCA modules is manual and time-consuming, we won't solve all the issues. You can contact us for specific cases if this is blocking the publication of your modules depending on OCA modules (please contact support@odoo-community.org).

    (almost) All the OCA modules are available in the OCA App Store : https://odoo-community.org/shop (that will be largerly improved in the next months).

    Greetings from the Spanish OCA Days in Cartagena,
    Virginie Dewulf
    Executive Director
    +32 477 64 17 20
    by Virginie Dewulf - 07:57 - 4 Jun 2025

    3 replies 3 replies

  • App Icon for Milk theme (Odoo 17+)
    For anyone interested, I created an SVG color scheme based on official app icons from the new milk theme.

    There is no official guidelines about designing an icon (shape+colors) that looks like Odoo's built-in apps but the "secret sauce" is about overlapping shapes to get this color mix

    --
    Yann PAPOUIN, Ingénieur R&D | DEC
    by Yann Papouin - 10:41 - 4 Jun 2025

    2 replies 2 replies

  • June OCA OWL Training!
    Dear contributors! 
    We are excited to share that in June, the OCA will provide a complete training on the Odoo framework "OWL"!
    We know you have been waiting for it.


    This training will be done in English.  A Spanish version of this training will be provided by the AEOdoo.

    We understand that some people from the American continent would have wanted to participate, and they will have the opportunity in the fall when we will host another session of the OWL training.

    Keep an eye out and don't hesitate to share this positive news within your community!

    --
    Julie LeBrun
    Content Creator & Training Manager
    by Julie LeBrun (OCA) - 01:02 - 2 Jun 2025
  • Debt transfer module?
    Hello!

    We have a requirement where employees report expenses they make and which later have to be reimbursed by the company. However, the vendor bill that gets generated from these expenses should belong on the actual providers of the service or good, not to the employee, which is the standard behavior.

    Do you know of any module or modules which allow us to transfer debts from the expense report?

    Thank you!
    by Samuel Macias Oropeza - 11:01 - 30 May 2025
  • OCA Zone at Odoo Experience - there is still room for you!
    Hello OCA Contributors.

    I hope this finds you all well.

    Earlier in the year I messaged about the OCA Zone at Odoo XP.
    I have heard from Odoo and we still have space for a few more to join us in our area!

    You just need to be a current OCA Sponsor. Very easy, you can become one right now, you'll see our newly updated sponsor packages here: https://odoo-community.org/get-involved/become-a-sponsor

    I will then get in touch and connect you with Odoo and they will invoice you directly for a standard booth in the OCA Zone at the Odoo XP. 

    We need to move pretty quickly on this for anyone else wanting to join, so get in touch with me ASAP and I will help get things rolling: rebecca@odoo-community.org

    We are really looking forward to having a great community environment this year and supporting each other!

    Warm regards,
    Rebecca

    --
    Rebecca Gellatly
    General Secretary
    Odoo Community Association
    by Rebecca Gellatly (OCA) - 04:31 - 26 May 2025
  • Demande de sponsoring – Projet Marathon international 2025-2027

    Bonjour,

    Je me permets de vous contacter afin de vous proposer un partenariat dans le cadre de mon projet sportif autour des marathons internationaux.

    Je suis un marathonien amateur de 37 ans, passionné par la course de fond, avec un record personnel de 2h45 établi lors du Marathon de Berlin en 2024. Mon objectif est ambitieux : descendre sous la barre des 2h40 au Marathon de Chicago en 2025. Ce défi s'inscrit dans un programme pluriannuel qui m'amènera également à participer aux prestigieux marathons de Boston et New York en 2026, ainsi qu’au Marathon de Belgrade en 2027.

    Dans cette optique, je suis à la recherche de partenaires susceptibles de m’apporter un soutien financier pour m’aider à couvrir les frais liés aux déplacements, inscriptions et logistique autour de ces compétitions.

    En contrepartie, je propose une visibilité régulière de la marque Odoo sur mes réseaux sociaux (Instagram, Facebook, Strava), ainsi qu’un flocage de votre logo sur mes équipements lors de ces événements internationaux très médiatisés.

    Je suis convaincu qu’un partenariat avec Odoo, entreprise innovante et dynamique, ferait sens dans le cadre de ce projet sportif basé sur la rigueur, la persévérance et la performance.

    Je reste à votre disposition pour discuter de cette proposition ou vous fournir un dossier plus détaillé.

    En vous remerciant par avance pour votre attention,
    Bien cordialement,

    Mason Morhet
    0479041314
    Rue Louis maréchal 119
    4360 Oreye 
    Belgique 

    by "mason morhet" <masmorhet@msn.com> - 03:35 - 24 May 2025

    1 attachments 1 attachments

    full.jpg

    1 replies 1 replies

    • Re: Demande de sponsoring – Projet Marathon international 2025-2027
      Hello,

      This mailing list is meant for the people contributing to the odoo community association, an independant organisation from Odoo S.A. company. Our communication language is English.

      You should contact Odoo company directly and not use this mailing list for such request in the future.

      Thanks and have a good run!
      Virginie Dewulf
      Executive Director
      +32 477 64 17 20

      Le sam. 24 mai 2025, 15:37, mason morhet <notifications@odoo-community.org> a écrit :

      Bonjour,

      Je me permets de vous contacter afin de vous proposer un partenariat dans le cadre de mon projet sportif autour des marathons internationaux.

      Je suis un marathonien amateur de 37 ans, passionné par la course de fond, avec un record personnel de 2h45 établi lors du Marathon de Berlin en 2024. Mon objectif est ambitieux : descendre sous la barre des 2h40 au Marathon de Chicago en 2025. Ce défi s'inscrit dans un programme pluriannuel qui m'amènera également à participer aux prestigieux marathons de Boston et New York en 2026, ainsi qu’au Marathon de Belgrade en 2027.

      Dans cette optique, je suis à la recherche de partenaires susceptibles de m’apporter un soutien financier pour m’aider à couvrir les frais liés aux déplacements, inscriptions et logistique autour de ces compétitions.

      En contrepartie, je propose une visibilité régulière de la marque Odoo sur mes réseaux sociaux (Instagram, Facebook, Strava), ainsi qu’un flocage de votre logo sur mes équipements lors de ces événements internationaux très médiatisés.

      Je suis convaincu qu’un partenariat avec Odoo, entreprise innovante et dynamique, ferait sens dans le cadre de ce projet sportif basé sur la rigueur, la persévérance et la performance.

      Je reste à votre disposition pour discuter de cette proposition ou vous fournir un dossier plus détaillé.

      En vous remerciant par avance pour votre attention,
      Bien cordialement,

      Mason Morhet
      0479041314
      Rue Louis maréchal 119
      4360 Oreye 
      Belgique 

      _______________________________________________
      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 - 05:16 - 24 May 2025
  • Handling 0% Tax in Invoices
    Dear Community,

    In version 18, Odoo already supports creating 0% taxes via https://github.com/odoo/odoo/pull/199144

    but it must config __keep_zero_line to True.
    I think this should add a new module account_move_zero_tax in OCA to allow this configuration more conveniently.

    Should I propose it under https://github.com/OCA/account-financial-tools or https://github.com/OCA/account-invoicing or has someone already contributed something similar?

    Thank you,
    Saran Lim.
    by saranl - 07:16 - 21 May 2025

    3 replies 3 replies

  • Restricting users to certain picking types

    Hello,


    I am looking for a way to restrict users to see only certain assigned stock picking types. I have found a module stock_picking_type_user_restriction in 12.0 with unfinished PRs to 13.0 and 14.0 but nothing more. Is there some other way on how to achieve this or is it woth porting this to more recent versions? Thank you very much.


    Best regards


        Radovan Skolnik

    by Radovan Skolnik - 04:51 - 16 May 2025

    2 replies 2 replies

    • Re: Restricting users to certain picking types

      Hello Roussel,


      thanks for the info. If no other idea is put forward I'll try to migrate this to 18.0 Shouldn't be that complicated looking at it.


      Best regards


          Radovan


      On piatok 16. mája 2025 17:01:55 CEST Roussel, Denis wrote:

      > Hello Radovan,

      >

      > >From my knowledge, nothing more exists to do so even in last versions.

      >

      > The last PR is this unfinished one : 

      > https://github.com/OCA/stock-logistics-warehouse/pull/1329 [1] I think this

      > can be reactivated by the author I am :-)

      > Regards,

      > On Fri, May 16, 2025 at 4:52 PM Radovan Skolnik <

      > notifications@odoo-community.org [2] > wrote: Hello,

      >

      > I am looking for a way to restrict users to see only certain assigned stock

      > picking types. I have found a module stock_picking_type_user_restriction in

      > 12.0 with unfinished PRs to 13.0 and 14.0 but nothing more. Is there some

      > other way on how to achieve this or is it woth porting this to more recent

      > versions? Thank you very much.

      >

      > Best regards

      >

      > Radovan Skolnik

      >

      > _______________________________________________

      > Mailing-List: https://odoo-community.org/groups/contributors-15 [3]

      > Post to: mailto: contributors@odoo-community.org [4]

      > Unsubscribe: https://odoo-community.org/groups?unsubscribe [5]

      >

      >

      > _______________________________________________

      > Mailing-List: https://odoo-community.org/groups/contributors-15 [6]

      > Post to: mailto:contributors@odoo-community.org

      > Unsubscribe: https://odoo-community.org/groups?unsubscribe [7]

      >

      >

      >

      > [1] https://github.com/OCA/stock-logistics-warehouse/pull/1329

      > [2] mailto:notifications@odoo-community.org

      > [3] https://odoo-community.org/groups/contributors-15

      > [4] mailto:contributors@odoo-community.org

      > [5] https://odoo-community.org/groups?unsubscribe

      > [6] https://odoo-community.org/groups/contributors-15

      > [7] https://odoo-community.org/groups?unsubscribe



      by Radovan Skolnik - 05:06 - 16 May 2025
    • Re: Restricting users to certain picking types
      Hello Radovan,

      From my knowledge, nothing more exists to do so even in last versions.

      The last PR is this unfinished one : https://github.com/OCA/stock-logistics-warehouse/pull/1329

      I think this can be reactivated by the author I am :-)


      Regards,

      On Fri, May 16, 2025 at 4:52 PM Radovan Skolnik <notifications@odoo-community.org> wrote:

      Hello,


      I am looking for a way to restrict users to see only certain assigned stock picking types. I have found a module stock_picking_type_user_restriction in 12.0 with unfinished PRs to 13.0 and 14.0 but nothing more. Is there some other way on how to achieve this or is it woth porting this to more recent versions? Thank you very much.


      Best regards


          Radovan Skolnik

      _______________________________________________
      Mailing-List: https://odoo-community.org/groups/contributors-15
      Post to: mailto:contributors@odoo-community.org
      Unsubscribe: https://odoo-community.org/groups?unsubscribe

      by Denis Roussel - 05:00 - 16 May 2025
  • AI Agents Usage

    Hi All,

     

    We are at new era where AI Agents are playing big roles in development, speeding up our late projects and providing new possibilities.

     

    I would like to trigger this email with 3 potential areas to cycle ideas/experience and share feedbacks

     

    • What experience you can share using AI Agent(s)?

    • How this would affect OCA repositories in migration versions and solving issues?

    • Possible new AI Agent(s) usage in Odoo?

     

     

    Sincerely,

     

    Hussain Al-Hammad | IT Consultant

    Development Experts Est  | Eastern Province | Saudi Arabia
    T +966 13 834 9560  |  M +966 56 963 4488

    hussain.hammad@dexberts.com  |  www.dexberts.com

     

    by hussain.hammad - 12:35 - 14 May 2025

    3 replies 3 replies

    • Re: AI Agents Usage

      Hi,
      I asked to copilot what is the latest versiom of odoo and it answered 17.

      I didnt try too much copilot but it's important to be careful about the version of odoo thay the LLM agent is trained, because maybe the generated code only works for older versions of odoo, and not for odoo 18.


      Cheers,
      Miguel.

      Sent with Proton Mail secure email.

      On Wednesday, May 14th, 2025 at 6:38 PM, Hussain Hammad <notifications@odoo-community.org> wrote:

      Hi All,

      We are at new era where AI Agents are playing big roles in development, speeding up our late projects and providing new possibilities.

      I would like to trigger this email with 3 potential areas to cycle ideas/experience and share feedbacks

      • What experience you can share using AI Agent(s)?

      • How this would affect OCA repositories in migration versions and solving issues?

      • Possible new AI Agent(s) usage in Odoo?

      Sincerely,

      Hussain Al-Hammad | IT Consultant

      Development Experts Est | Eastern Province | Saudi Arabia
      T +966 13 834 9560 | M +966 56 963 4488

      hussain.hammad@dexberts.com | www.dexberts.com

      _______________________________________________
      Mailing-List: https://odoo-community.org/groups/contributors-15
      Post to: mailto:contributors@odoo-community.org
      Unsubscribe: https://odoo-community.org/groups?unsubscribe


      by python3developer - 03:56 - 20 May 2025
    • RE: AI Agents Usage

      I totally agree on this: “It concerns me that novice contributors will rely first on AI to generate the code and then later on maintainers to understand and validate it.” There is a big misunderstanding that AI Agents are magical and its code can be trusted without proper validation (line by line).

       

      May be I’m not asking the right question!

       

      Does anyone of OCA Contributors use any sort of AI tools or IDE’s? and if not, why?

       

       

      -Hussain Hammad

       

      From: Adam Heinz <notifications@odoo-community.org>
      Sent: Wednesday, May 14, 2025 2:53 PM
      To: Contributors <contributors@odoo-community.org>
      Subject: Re: AI Agents Usage

       

      Insofar as AI contributions to OCA projects go:

       

      """

      Unfortunately, there is still no way for users to determine if a particular piece of code generated by Copilot is original or derived from code repositories that may be safeguarded by a license.

      """

       

      That article is from 2023, so perhaps the situation has improved since, but I still find it legally dubious.

       

      """

      Just like when you write any code that uses material you did not independently originate, you should take precautions to understand how it works and ensure its suitability. These include rigorous testing, IP scanning, and checking for security vulnerabilities. You should make sure your IDE or editor does not automatically compile or run generated code before you review it.

      """

       

      It concerns me that novice contributors will rely first on AI to generate the code and then later on maintainers to understand and validate it.

       

       

       

      On Wed, May 14, 2025 at 6:37 AM Hussain Hammad <notifications@odoo-community.org> wrote:

      Hi All,

       

      We are at new era where AI Agents are playing big roles in development, speeding up our late projects and providing new possibilities.

       

      I would like to trigger this email with 3 potential areas to cycle ideas/experience and share feedbacks

       

      • What experience you can share using AI Agent(s)?

      • How this would affect OCA repositories in migration versions and solving issues?

      • Possible new AI Agent(s) usage in Odoo?

       

       

      Sincerely,

       

      Hussain Al-Hammad | IT Consultant

      Development Experts Est  | Eastern Province | Saudi Arabia
      T +966 13 834 9560  |  M +966 56 963 4488

      hussain.hammad@dexberts.com  |  www.dexberts.com

       

      _______________________________________________
      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 - 02:31 - 16 May 2025
    • Re: AI Agents Usage
      Insofar as AI contributions to OCA projects go:

      """
      Unfortunately, there is still no way for users to determine if a particular piece of code generated by Copilot is original or derived from code repositories that may be safeguarded by a license.
      """

      That article is from 2023, so perhaps the situation has improved since, but I still find it legally dubious.

      """
      Just like when you write any code that uses material you did not independently originate, you should take precautions to understand how it works and ensure its suitability. These include rigorous testing, IP scanning, and checking for security vulnerabilities. You should make sure your IDE or editor does not automatically compile or run generated code before you review it.
      """

      It concerns me that novice contributors will rely first on AI to generate the code and then later on maintainers to understand and validate it.



      On Wed, May 14, 2025 at 6:37 AM Hussain Hammad <notifications@odoo-community.org> wrote:

      Hi All,

       

      We are at new era where AI Agents are playing big roles in development, speeding up our late projects and providing new possibilities.

       

      I would like to trigger this email with 3 potential areas to cycle ideas/experience and share feedbacks

       

      • What experience you can share using AI Agent(s)?

      • How this would affect OCA repositories in migration versions and solving issues?

      • Possible new AI Agent(s) usage in Odoo?

       

       

      Sincerely,

       

      Hussain Al-Hammad | IT Consultant

      Development Experts Est  | Eastern Province | Saudi Arabia
      T +966 13 834 9560  |  M +966 56 963 4488

      hussain.hammad@dexberts.com  |  www.dexberts.com

       

      _______________________________________________
      Mailing-List: https://odoo-community.org/groups/contributors-15
      Post to: mailto:contributors@odoo-community.org
      Unsubscribe: https://odoo-community.org/groups?unsubscribe

      by Adam Heinz - 01:51 - 14 May 2025
  • Show count of versions in documents app

    Hello together,

     

    in the documents app kanban view I want to show the count of versions for this document if more than 1 version of this document exists. I try several ways to implement that logic but I do not get it. How is the logic between documents.document and ir.attachment. I do not find id’s or keys to connect this two modells and in some cases I didn’t get a dataset in ir_attachment for the version.

    Thanks a lot.

    Best regards,

    Matthias

     

    Matthias Ellmerer

     

    signature_3768892847
    digitalisierung & software

     

    signature_2963947848signature_2285442988signature_3236691532


    📍 Sonnendorf 33a, 6334 Schwoich | Austria
    📞 +43 664 353 87 33 · 🌐 implema.at  

     

    by Matthias Ellmerer - 01:30 - 7 May 2025

    4 attachments 4 attachments

    image004[57].png
    image003[4].png
    image002[55].png
    image001[92].png
  • Fwd: Crowdfunding module 
    Hi everyone,

Please your attention to the following repo that we want to create, in 
order to support an OCA board initiative where we want to make it easier 
for contributors to crowdfund module development, or Openupgrade 
development, like was talked about often in the past at OCA days.

https://github.com/OCA/repo-maintainer-conf/pull/89

-Tom
    by Tom Blauwendraat - 09:01 - 7 May 2025
  • Removal of migration scripts on each new version
    Hi,

    the migration guide mandates the following

    > Remove any possible migration script from previous version (in a nutshell, remove migrations folder inside the module if exists).

    (https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-18.0#tasks-to-do-in-the-migration)

    However, it is not uncommon to skip versions when migrating an Odoo instance. You would go from 15.0 or 16.0 to 18.0 rather than migrating every year. When using the Odoo enterprise migration, the migration scripts between the source and the target version are supposed to be present in the target version. So the migration guideline breaks this type of migration.

    I had a disagreement with Pedro Baeza about this on one PR, but I keep coming across instances of this such as https://github.com/OCA/account-invoicing/pull/1874 today so I would like to discuss this in a wider audience.

    My preference would be for the guideline to change to say that it is allowed to keep some of the scripts if they are safe for inclusion in the later version (such as the script from https://github.com/OCA/account-invoicing/pull/1874, which checks if a field already exists before trying to add it).

    Can I have a temperature check from the community to see how you all feel about this?

    Best regards,
    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
    by Stefan Rijnhart - 01:00 - 6 May 2025

    23 replies 23 replies

    • Re: Removal of migration scripts on each new version

      Hi, although at first I thought it was a good idea to keep the migration scripts, I now believe there are stronger reasons not to.

      Recently, I was working on a migration from version 12 to 16 of an Odoo Enterprise database with a significant number of OCA modules.

      I’ve built a small script that collects all the relevant migration scripts based on a CSV file specifying the installed modules and the URL of the corresponding OCA repositories:
      👉 https://github.com/javierjcf/odoo-mig-analyzer

      The script is just an initial idea — it takes the list of installed modules from a CSV and generates .txt and .csv files grouped by repository, listing the modules that contain migrations. It can also save these into a directory, which makes analysis easier. However, it’s still necessary to manually build a script that performs the specific migration actions you need from each of them.

      The idea is to take the migrated database returned by Odoo, then run a script in odoo shell that executes the necessary migration scripts for your project. After that, you perform an update all to trigger the final version’s migrations, ensuring all prior scripts were executed.

      The problem: When trying to launch odoo shell, you often encounter errors that require running a first update all, which upgrades the OCA modules to version 16—potentially skipping or breaking some migration scripts that should have run earlier. Also, some scripts may rely on code from the original version, making them incompatible at this stage.

      At this point, the process seems too unreliable. One workaround I considered was running everything directly in SQL, but that could become quite complex depending on the module.

      Right now, I think it’s more practical to use OpenUpgrade to migrate the Enterprise database. Then, manually write scripts to handle the Enterprise modules in use—at least in our case, OCA modules far outnumber the Enterprise ones.

      There really doesn’t seem to be a reliable migration process for Enterprise databases with many OCA modules. The fact that you can’t reliably run all the migration scripts at the correct version steps makes the entire process fragile.

      Does anyone have any ideas on how to make this process more reliable?


      El mié, 7 may 2025 a las 15:53, Richard deMeester (<notifications@odoo-community.org>) escribió:

      Hmm,

      I would argue the opposite.  It is rare that a migration is dangerous to leave in.  If a cetain feature is deprectated in the future that makes the migration irrelevant or wrong, then it needs to be adjusted or taken out.

      But if something needs to be populated if going from 16.0.0 -> 16.0.1, then by extension, it is almost certainly needed if going from 14 -> 18....

      I think part of making changes and adding features is writing relevant migrations, and checking that other migrations are still relevant.

      Kind regards,
      Richard deMeester
      Development QA
      WilldooIT website
      Facebook
      LinkedIn
      PNORS website
      Pacific Commerce website
      WilldooIT website
      Netway Networks website
      WilldooIT is a member of the PNORS Technology Group.
      This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, you may not disclose or use the information in this email in any way. If you have received this email in error please notify the sender. Although reasonable precautions have been taken to ensure no viruses are present in this email, no responsibility is accepted by PNORS Technology Group Pty Ltd or its related entities for any loss or damage arising from the use of this email or attachments. Any views expressed in this email or file attachments are those of the individual sender only, unless expressly stated to be those of PNORS Technology Group Pty Ltd or any of its related entities.
          
      From: Enric Tobella Alomar <notifications@odoo-community.org>
      Sent: Wednesday, 7 May 2025 8:52 PM
      To: Contributors <contributors@odoo-community.org>
      Subject: Re: Removal of migration scripts on each new version
       
      I prefer to remove the scripts.

      The reason is simple, it is safer. 

      Keeping them might work in some cases, but it might be problematic in others. It is true that as a community, we don't want to make life harder for community or enterprise developers. However, our duty is to deliver the safest option.

      We cannot ask a developer to take into account if this change might affect when coming from 12 or 13 or 14 or.... it is easier to take into account just the current version.

      I understand that in some specific cases, with a strong maintainer behind the project, it might have sense, but not as a rule.

      Also, with the latest versions (with the scripts folder) it might be easy to create an aggregator of scripts. If you want, we can do a work table on this topic on the next OCA Days (On Belgium or in Spain)

      My 2 cents.

      El mié, 7 may 2025 a las 12:27, Sebastien Alix (<notifications@odoo-community.org>) escribió:

      Hello,

      Overall I tend to agree with Pedro on this topic. At C2C we are often jumping 2 to 4 versions when migrating a database, so we are not migrating version by version regarding OCA modules (it would take too much time), and by experience:

      • often `pre` scripts can run without adaptation (that could happen of course with all reasons written by Pedro above), as they normally only rely on SQL
      • `post` ones that are using Odoo ORM can be broken easily (i.e. invoking a 16.0 post script with an 18.0 Odoo code base), and therefore requires modifications (making such script idempotent will require extra work from contributors if we go that way)

      To ease the migration work, we are starting to use a tool that reports all intermediate migration scripts for a given module (things start to be complicated when a module is renamed/changed repo but it's another story), and we check which one is relevant for the migration. After that we consolidate these migration scripts (copy/paste + some adaptations) locally in the project.

      => often, some migration scripts could be avoided, and we keep only ones that make sense for the migration. I do not have exact figures but if we have let's say 4 migration scripts for a module from 14.0 to 18.0, often we land with only 1 or 2 that are relevant and could ignore remaining ones.
      => from what I see currently in our biggest projects jumping 4 versions, modules impacted by these intermediate migration scripts represent less than 10% of  installed OCA modules
      => its easier/faster for us to get these info before we start a migration and consolidate scripts manually afterwards, than ensuring every intermediate migration scripts will be idempotent to ensure versions jump. It's not perfect, but that works...

      Note: Pushing this tool in community is complicated for now (for different reasons, and we are lacking of time, things still need to be discussed), but I would like to see that happening later one way or another to consolidate community knowledge and contributions (but this is another topic than the one discussed here).

      That said, I'm not against keeping some of these scripts if it makes life easier, like the one for `queue_job`, but by default it's easier to drop them IMO, and during review maintainers could state if it deserves to be kept?


      Le 06/05/2025 à 13:02, Stefan Rijnhart a écrit :
      Hi,

      the migration guide mandates the following

      > Remove any possible migration script from previous version (in a nutshell, remove migrations folder inside the module if exists).

      (https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-18.0#tasks-to-do-in-the-migration)

      However, it is not uncommon to skip versions when migrating an Odoo instance. You would go from 15.0 or 16.0 to 18.0 rather than migrating every year. When using the Odoo enterprise migration, the migration scripts between the source and the target version are supposed to be present in the target version. So the migration guideline breaks this type of migration.

      I had a disagreement with Pedro Baeza about this on one PR, but I keep coming across instances of this such as https://github.com/OCA/account-invoicing/pull/1874 today so I would like to discuss this in a wider audience.

      My preference would be for the guideline to change to say that it is allowed to keep some of the scripts if they are safe for inclusion in the later version (such as the script from https://github.com/OCA/account-invoicing/pull/1874, which checks if a field already exists before trying to add it).

      Can I have a temperature check from the community to see how you all feel about this?

      Best regards,
      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
      -- 
Sébastien Alix
Business Solutions Odoo Developer

Camptocamp France SA
https://www.camptocamp.com/

      _______________________________________________
      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 Alomar
      CEO & Founder

      _______________________________________________
      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 Javier Colmenero Fernández - 04:46 - 7 May 2025
    • Re: Removal of migration scripts on each new version

      Hmm,

      I would argue the opposite.  It is rare that a migration is dangerous to leave in.  If a cetain feature is deprectated in the future that makes the migration irrelevant or wrong, then it needs to be adjusted or taken out.

      But if something needs to be populated if going from 16.0.0 -> 16.0.1, then by extension, it is almost certainly needed if going from 14 -> 18....

      I think part of making changes and adding features is writing relevant migrations, and checking that other migrations are still relevant.

      Kind regards,
      Richard deMeester
      Development QA
      WilldooIT website
      Facebook
      LinkedIn
      PNORS website
      Pacific Commerce website
      WilldooIT website
      Netway Networks website
      WilldooIT is a member of the PNORS Technology Group.
      This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to which they are addressed. If you are not the intended recipient, you may not disclose or use the information in this email in any way. If you have received this email in error please notify the sender. Although reasonable precautions have been taken to ensure no viruses are present in this email, no responsibility is accepted by PNORS Technology Group Pty Ltd or its related entities for any loss or damage arising from the use of this email or attachments. Any views expressed in this email or file attachments are those of the individual sender only, unless expressly stated to be those of PNORS Technology Group Pty Ltd or any of its related entities.
          
      From: Enric Tobella Alomar <notifications@odoo-community.org>
      Sent: Wednesday, 7 May 2025 8:52 PM
      To: Contributors <contributors@odoo-community.org>
      Subject: Re: Removal of migration scripts on each new version
       
      I prefer to remove the scripts.

      The reason is simple, it is safer. 

      Keeping them might work in some cases, but it might be problematic in others. It is true that as a community, we don't want to make life harder for community or enterprise developers. However, our duty is to deliver the safest option.

      We cannot ask a developer to take into account if this change might affect when coming from 12 or 13 or 14 or.... it is easier to take into account just the current version.

      I understand that in some specific cases, with a strong maintainer behind the project, it might have sense, but not as a rule.

      Also, with the latest versions (with the scripts folder) it might be easy to create an aggregator of scripts. If you want, we can do a work table on this topic on the next OCA Days (On Belgium or in Spain)

      My 2 cents.

      El mié, 7 may 2025 a las 12:27, Sebastien Alix (<notifications@odoo-community.org>) escribió:

      Hello,

      Overall I tend to agree with Pedro on this topic. At C2C we are often jumping 2 to 4 versions when migrating a database, so we are not migrating version by version regarding OCA modules (it would take too much time), and by experience:

      • often `pre` scripts can run without adaptation (that could happen of course with all reasons written by Pedro above), as they normally only rely on SQL
      • `post` ones that are using Odoo ORM can be broken easily (i.e. invoking a 16.0 post script with an 18.0 Odoo code base), and therefore requires modifications (making such script idempotent will require extra work from contributors if we go that way)

      To ease the migration work, we are starting to use a tool that reports all intermediate migration scripts for a given module (things start to be complicated when a module is renamed/changed repo but it's another story), and we check which one is relevant for the migration. After that we consolidate these migration scripts (copy/paste + some adaptations) locally in the project.

      => often, some migration scripts could be avoided, and we keep only ones that make sense for the migration. I do not have exact figures but if we have let's say 4 migration scripts for a module from 14.0 to 18.0, often we land with only 1 or 2 that are relevant and could ignore remaining ones.
      => from what I see currently in our biggest projects jumping 4 versions, modules impacted by these intermediate migration scripts represent less than 10% of  installed OCA modules
      => its easier/faster for us to get these info before we start a migration and consolidate scripts manually afterwards, than ensuring every intermediate migration scripts will be idempotent to ensure versions jump. It's not perfect, but that works...

      Note: Pushing this tool in community is complicated for now (for different reasons, and we are lacking of time, things still need to be discussed), but I would like to see that happening later one way or another to consolidate community knowledge and contributions (but this is another topic than the one discussed here).

      That said, I'm not against keeping some of these scripts if it makes life easier, like the one for `queue_job`, but by default it's easier to drop them IMO, and during review maintainers could state if it deserves to be kept?


      Le 06/05/2025 à 13:02, Stefan Rijnhart a écrit :
      Hi,

      the migration guide mandates the following

      > Remove any possible migration script from previous version (in a nutshell, remove migrations folder inside the module if exists).

      (https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-18.0#tasks-to-do-in-the-migration)

      However, it is not uncommon to skip versions when migrating an Odoo instance. You would go from 15.0 or 16.0 to 18.0 rather than migrating every year. When using the Odoo enterprise migration, the migration scripts between the source and the target version are supposed to be present in the target version. So the migration guideline breaks this type of migration.

      I had a disagreement with Pedro Baeza about this on one PR, but I keep coming across instances of this such as https://github.com/OCA/account-invoicing/pull/1874 today so I would like to discuss this in a wider audience.

      My preference would be for the guideline to change to say that it is allowed to keep some of the scripts if they are safe for inclusion in the later version (such as the script from https://github.com/OCA/account-invoicing/pull/1874, which checks if a field already exists before trying to add it).

      Can I have a temperature check from the community to see how you all feel about this?

      Best regards,
      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
      -- 
Sébastien Alix
Business Solutions Odoo Developer

Camptocamp France SA
https://www.camptocamp.com/

      _______________________________________________
      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 Alomar
      CEO & 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 "Richard deMeester" <richard.demeester@willdooit.com> - 03:51 - 7 May 2025

      12 attachments 12 attachments

      image221226.png
      image948425.png
      image699922.png
      image361297.png
      image880946.png
      image764316.png
      image090265.png
      image843456.png
      image767652.png
      image615154.png
      image740632.png
      image245587.png
    • Re: Removal of migration scripts on each new version 
      Hi everybody,

thank you for your input. Some good points have been raised indeed not 
to keep the scripts by default:

* By assuming that keeping the migration script helps people, we might 
underestimate the ability of developers and consultants to recover from 
their absence. In this light, arguably, breaking a migration process 
with an invalid migration script might make things worse than having no 
migration at all, at least for non-developers.
* While in my experience migration scripts are testable, such tests are 
rare and may not be worthwhile and as such the untested migration 
scripts will lack the quality assurance that is the OCA seal.
* As a party that does a lot of migrations in the way that would 
potentially benefit by keeping the scripts, C2C has indicated that they 
prefer to use a bespoke selection of scripts.

I have also been browsing the migration scripts in 15.0, 16.0 and 17.0. 
On average, 5% of all modules have a migration script for the current 
version. For sure there are some scripts that are going to cause issues 
in later versions (scripts that update translatable fields using SQL 
before the translation refactoring, or scripts that query ir.property). 
At the same time, there are lots of scripts that are unproblematic for 
the next version. Most scripts are short and easy to review.

So I would still be interested to pursue a more pragmatic approach for 
this on the project/module/maintainer level, as Stéphane suggests below 
(and Sebasien Alix also hinted at). So that when we maintain, migrate, 
or review a module we can put in the extra effort to vouch for an older 
migration script to work on the next version. The policy would then 
still be to drop the scripts by default. Would that be something we can 
settle on?

On 07-05-2025 12:12, Stéphane Bidoul wrote:

> As a maintainer I would like to have the liberty of keeping the 

> migration scripts if I want to, as I think it is a good service to 

> provide to my users.

>

> In the modules I help maintaining it is usually not a problem nor 

> difficulty. For instance in mis_builder and queue_job It's likely that 

> we could have all the scripts for the past 8 versions run on the latest.

>

> So I don't quite understand why it is forbidden to keep them. If I 

> want to take responsibility for maintaining them I should be allowed 

> to do so.

>

> Best regards,

>

> -Stéphane


-- 
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
      by Stefan Rijnhart - 03:48 - 7 May 2025
    • Re: Removal of migration scripts on each new version
      I prefer to remove the scripts.

      The reason is simple, it is safer. 

      Keeping them might work in some cases, but it might be problematic in others. It is true that as a community, we don't want to make life harder for community or enterprise developers. However, our duty is to deliver the safest option.

      We cannot ask a developer to take into account if this change might affect when coming from 12 or 13 or 14 or.... it is easier to take into account just the current version.

      I understand that in some specific cases, with a strong maintainer behind the project, it might have sense, but not as a rule.

      Also, with the latest versions (with the scripts folder) it might be easy to create an aggregator of scripts. If you want, we can do a work table on this topic on the next OCA Days (On Belgium or in Spain)

      My 2 cents.

      El mié, 7 may 2025 a las 12:27, Sebastien Alix (<notifications@odoo-community.org>) escribió:

      Hello,

      Overall I tend to agree with Pedro on this topic. At C2C we are often jumping 2 to 4 versions when migrating a database, so we are not migrating version by version regarding OCA modules (it would take too much time), and by experience:

      • often `pre` scripts can run without adaptation (that could happen of course with all reasons written by Pedro above), as they normally only rely on SQL
      • `post` ones that are using Odoo ORM can be broken easily (i.e. invoking a 16.0 post script with an 18.0 Odoo code base), and therefore requires modifications (making such script idempotent will require extra work from contributors if we go that way)

      To ease the migration work, we are starting to use a tool that reports all intermediate migration scripts for a given module (things start to be complicated when a module is renamed/changed repo but it's another story), and we check which one is relevant for the migration. After that we consolidate these migration scripts (copy/paste + some adaptations) locally in the project.

      => often, some migration scripts could be avoided, and we keep only ones that make sense for the migration. I do not have exact figures but if we have let's say 4 migration scripts for a module from 14.0 to 18.0, often we land with only 1 or 2 that are relevant and could ignore remaining ones.
      => from what I see currently in our biggest projects jumping 4 versions, modules impacted by these intermediate migration scripts represent less than 10% of  installed OCA modules
      => its easier/faster for us to get these info before we start a migration and consolidate scripts manually afterwards, than ensuring every intermediate migration scripts will be idempotent to ensure versions jump. It's not perfect, but that works...

      Note: Pushing this tool in community is complicated for now (for different reasons, and we are lacking of time, things still need to be discussed), but I would like to see that happening later one way or another to consolidate community knowledge and contributions (but this is another topic than the one discussed here).

      That said, I'm not against keeping some of these scripts if it makes life easier, like the one for `queue_job`, but by default it's easier to drop them IMO, and during review maintainers could state if it deserves to be kept?


      Le 06/05/2025 à 13:02, Stefan Rijnhart a écrit :
      Hi,

      the migration guide mandates the following

      > Remove any possible migration script from previous version (in a nutshell, remove migrations folder inside the module if exists).

      (https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-18.0#tasks-to-do-in-the-migration)

      However, it is not uncommon to skip versions when migrating an Odoo instance. You would go from 15.0 or 16.0 to 18.0 rather than migrating every year. When using the Odoo enterprise migration, the migration scripts between the source and the target version are supposed to be present in the target version. So the migration guideline breaks this type of migration.

      I had a disagreement with Pedro Baeza about this on one PR, but I keep coming across instances of this such as https://github.com/OCA/account-invoicing/pull/1874 today so I would like to discuss this in a wider audience.

      My preference would be for the guideline to change to say that it is allowed to keep some of the scripts if they are safe for inclusion in the later version (such as the script from https://github.com/OCA/account-invoicing/pull/1874, which checks if a field already exists before trying to add it).

      Can I have a temperature check from the community to see how you all feel about this?

      Best regards,
      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

      -- 
Sébastien Alix
Business Solutions Odoo Developer

Camptocamp France SA
https://www.camptocamp.com/

      _______________________________________________
      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 Alomar
      CEO & Founder

      by Enric Tobella Alomar - 12:51 - 7 May 2025
    • Re: Removal of migration scripts on each new version

      Hello,

      Overall I tend to agree with Pedro on this topic. At C2C we are often jumping 2 to 4 versions when migrating a database, so we are not migrating version by version regarding OCA modules (it would take too much time), and by experience:

      • often `pre` scripts can run without adaptation (that could happen of course with all reasons written by Pedro above), as they normally only rely on SQL
      • `post` ones that are using Odoo ORM can be broken easily (i.e. invoking a 16.0 post script with an 18.0 Odoo code base), and therefore requires modifications (making such script idempotent will require extra work from contributors if we go that way)

      To ease the migration work, we are starting to use a tool that reports all intermediate migration scripts for a given module (things start to be complicated when a module is renamed/changed repo but it's another story), and we check which one is relevant for the migration. After that we consolidate these migration scripts (copy/paste + some adaptations) locally in the project.

      => often, some migration scripts could be avoided, and we keep only ones that make sense for the migration. I do not have exact figures but if we have let's say 4 migration scripts for a module from 14.0 to 18.0, often we land with only 1 or 2 that are relevant and could ignore remaining ones.
      => from what I see currently in our biggest projects jumping 4 versions, modules impacted by these intermediate migration scripts represent less than 10% of  installed OCA modules
      => its easier/faster for us to get these info before we start a migration and consolidate scripts manually afterwards, than ensuring every intermediate migration scripts will be idempotent to ensure versions jump. It's not perfect, but that works...

      Note: Pushing this tool in community is complicated for now (for different reasons, and we are lacking of time, things still need to be discussed), but I would like to see that happening later one way or another to consolidate community knowledge and contributions (but this is another topic than the one discussed here).

      That said, I'm not against keeping some of these scripts if it makes life easier, like the one for `queue_job`, but by default it's easier to drop them IMO, and during review maintainers could state if it deserves to be kept?


      Le 06/05/2025 à 13:02, Stefan Rijnhart a écrit :
      Hi,

      the migration guide mandates the following

      > Remove any possible migration script from previous version (in a nutshell, remove migrations folder inside the module if exists).

      (https://github.com/OCA/maintainer-tools/wiki/Migration-to-version-18.0#tasks-to-do-in-the-migration)

      However, it is not uncommon to skip versions when migrating an Odoo instance. You would go from 15.0 or 16.0 to 18.0 rather than migrating every year. When using the Odoo enterprise migration, the migration scripts between the source and the target version are supposed to be present in the target version. So the migration guideline breaks this type of migration.

      I had a disagreement with Pedro Baeza about this on one PR, but I keep coming across instances of this such as https://github.com/OCA/account-invoicing/pull/1874 today so I would like to discuss this in a wider audience.

      My preference would be for the guideline to change to say that it is allowed to keep some of the scripts if they are safe for inclusion in the later version (such as the script from https://github.com/OCA/account-invoicing/pull/1874, which checks if a field already exists before trying to add it).

      Can I have a temperature check from the community to see how you all feel about this?

      Best regards,
      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

      -- 
Sébastien Alix
Business Solutions Odoo Developer

Camptocamp France SA
https://www.camptocamp.com/
      by Sébastien Alix - 12:26 - 7 May 2025

  • SAAS solution
    Dear Sir/Madam,

    I hope this email finds you well.

    We are seeking a solution for deploying Odoo as a SaaS offering. While Webkul's solution appears promising, we are exploring community-based alternatives. Could you advise on the optimal approach and best practices for deploying a community Odoo solution as a SaaS?

    Thank you.

    Sincerely,

    Abdulbasit Suleiman
    by basit.suleiman91 - 04:51 - 6 May 2025

    1 replies 1 replies

    • Re: SAAS solution
      Internal communication: I'm not going to promote anything here, but you can have a look at this: https://www.youtube.com/watch?v=TNVrOxVeHgM----- Original message ----- [...] ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​

      I'm not going to promote anything here, but you can have a look at this: https://www.youtube.com/watch?v=TNVrOxVeHgM

      Best regards,

      photograph
      Ivan Sokolov
       Cetmix Odoo Solutions
      cetmix.com
      Facebook Twitter LinkedIn Instagram 
      This message is sent using Mail Messages Easy app


      ----- Original message -----
      Date: May 6, 2025, 4:53:15 AM
      From: Notifications
      Subject: SAAS solution

      Dear Sir/Madam,

      I hope this email finds you well.

      We are seeking a solution for deploying Odoo as a SaaS offering. While Webkul's solution appears promising, we are exploring community-based alternatives. Could you advise on the optimal approach and best practices for deploying a community Odoo solution as a SaaS?

      Thank you.

      Sincerely,

      Abdulbasit Suleiman

      _______________________________________________
      Mailing-List: https://odoo-community.org/groups/contributors-15
      Post to: mailto:contributors@odoo-community.org
      Unsubscribe: https://odoo-community.org/groups?unsubscribe

      Powered by Messages Easy Pro

      by "Ivan Sokolov via Cetmix OÜ" <team@cetmix.com> - 01:00 - 6 May 2025
  • Analytic info on inventory adjustments (Odoo 17)
    Hello,

    Do we have a module on Odoo 17 to set the analytic information when doing an inventory adjustment?

    I found something on previous versions and inventory line and I was wondering if it was migrated somewhere in a different repo.

    Thank you!

    MAXIME CHAMBREUIL
    DIRECTOR INTERNACIONAL
    T: +52 (800) 953-2012 #5200
    M: +52 (442) 114-9164 | WhatsApp
    C: MChambreuil@OpenSourceIntegrators.com
    Av. Antea 1032, Piso 4 Local 8, Colonia Jurica
    Santiago de Querétaro, Querétaro, 76100, México

    Analizar. Optimizar. Automatizar. Transicionar.

    by Maxime Chambreuil - 08:56 - 5 May 2025

    2 replies 2 replies

  • New typesense and odoo connector
    Typesense is a search engine and using new module we can index whatever data we want friendly without needing for coding special serializing functions for each form of data we want to send.


    happy for review

    Typesense is a powerful easy to configure search engine.
    by Mohamed Alkobrosly - 03:45 - 1 May 2025
  • Partnership with Flatio

    Partnership with Flatio

    Hello!

    are you open to content collaboration? I’m reaching out from Flatio, a platform offering mid-term housing solutions.

    I’d love to explore publishing an article or adding links to existing content.

    In return, you can place your link to some of our articles in our blog or send us your own. 

    Looking forward to hearing your thoughts!

    Have a lovely day,



    Jitka Pálešová
    Marketing & Partnership


    Unlock your freedom with Flatio
    +420 734 204 972

        
    Copyright © 2025 Flatio, s.r.o., All rights reserved.

    Want to change how you receive these emails?
    You can unsubscribe.
     
    by "Flatio" <partners@flatio.com> - 03:51 - 29 Apr 2025
  • 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.

    Denis Roussel
    Software Engineer
    T    : +32 2 888 31 49
    M : +32 472 22 00 57


    Val Benoit, Quai Banning 6 | B-4000 Liège | Belgium
    Atrium Building, Drève Richelle 167 | B-1410 Waterloo | Belgium
    Zone industrielle 22 | L-8287 Kehlen | Luxembourg
    by Denis Roussel - 05:56 - 28 Apr 2025

    5 replies 5 replies

  • [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

    1 attachments 1 attachments

    Screenshot 2025-04-28 at 10.16.30.png

    2 replies 2 replies

    • 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 ADJAKOUN

      Le lun. 28 avr. 2025 à 10:53, Tris Doan <notifications@odoo-community.org> a écrit :
      Hello,

      Have you checked this PR?

      Best regards,

      Tris Doan


      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
      Hello,

      Have you checked this PR?

      Best regards,

      Tris Doan


      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
  • 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

    1 attachments 1 attachments

    diwBymTwDDYd1bho.png

    3 replies 3 replies

    • Re: Odoo Module Dependency Visualisation
      Internal communication: Actually there is a non OCA but open source module that does the same thing. https://apps.odoo.com/apps/modules/18.0/cx_odoo_plantuml ----- [...] ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​ ͏ ​

      Actually there is a non OCA but open source module that does the same thing.

      https://apps.odoo.com/apps/modules/18.0/cx_odoo_plantuml


      Best regards,

      photograph
      Ivan Sokolov
       Cetmix Odoo Solutions
      cetmix.com
      Facebook Twitter LinkedIn Instagram 
      This message is sent using Mail Messages Easy app


      ----- Original message -----
      Date: May 1, 2025, 10:12:53 AM
      From: Notifications
      Subject: Re: Odoo Module Dependency Visualisation

      Hello

      Great tool !

      It could be supercool if you colorize depending on the licence... it could show if licence inheritance is correct for a project...
      for instance OPL-1 should not inherit AGPL-3...

      Bravo

      --------------------------------
      Cyril VINH-TUNG
      INVITU
      Computer & Network Engineering
      BP 32 - 98713 Papeete - French Polynesia
      Tél: +689 40 46 11 99
      contact@invitu.com

      Le ven. 25 avr. 2025, 04:33, Janik von Rotz <notifications@odoo-community.org> a écrit :

      _______________________________________________
      Mailing-List: https://odoo-community.org/groups/contributors-15
      Post to: mailto:contributors@odoo-community.org
      Unsubscribe: https://odoo-community.org/groups?unsubscribe

      Powered by Messages Easy Pro

      by "Ivan Sokolov via Cetmix OÜ" <team@cetmix.com> - 10:21 - 1 May 2025
    • Re: Odoo Module Dependency Visualisation
      Hello

      Great tool !

      It could be supercool if you colorize depending on the licence... it could show if licence inheritance is correct for a project...
      for instance OPL-1 should not inherit AGPL-3...

      Bravo

      --------------------------------
      Cyril VINH-TUNG
      INVITU
      Computer & Network Engineering
      BP 32 - 98713 Papeete - French Polynesia
      Tél: +689 40 46 11 99
      contact@invitu.com

      Le ven. 25 avr. 2025, 04:33, Janik von Rotz <notifications@odoo-community.org> a écrit :

      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

      _______________________________________________
      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 - 10:11 - 1 May 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
  • 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