Archives
Contributors
-
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-sponsorI 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.orgWe are really looking forward to having a great community environment this year and supporting each other!Warm regards,Rebecca--Rebecca GellatlyGeneral SecretaryOdoo Community Association
by Rebecca Gellatly (OCA) - 04:31 - 26 May 2025 -
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!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 Morhet0479041314Rue Louis maréchal 1194360 OreyeBelgique
_______________________________________________
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 -
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 Morhet0479041314Rue Louis maréchal 1194360 OreyeBelgique
by "mason morhet" <masmorhet@msn.com> - 03:35 - 24 May 2025 -
Re: Handling 0% Tax in Invoices
Hi,I don't especially care to be honest. No Western regimes require this, or even much care about your internal accounting.But I would also consider that a country specific requirement is usually better added to the localisation in Odoo core. They are usually pretty responsive to l10n errors, just show them the links to the legislation/requirement,and propose a PR.On Wed, May 21, 2025 at 6:57 PM Saran Limpajitkutaporn <notifications@odoo-community.org> wrote:Hi Graeme,Thank you for your reply, and sorry for the misleading post.Yes, Odoo already supports 0% taxes,
but previously it didn’t add a tax line with 0 value, and there was no way to configure it.
Now, with this core improvement, it’s possible to hook into that behavior.I believe this kind of module would still be useful in OCA,
especially for countries (like mine) where showing 0% tax lines is required.I agree that the name should be more accurate — maybe account_move_keep_zero_tax_line would be better. What do you think?Thank you,Saran Lim.On Wed, May 21, 2025 at 12:47 PM Graeme Gellatly <notifications@odoo-community.org> wrote:Hi,This is a bit of a misleading post and module name. Odoo supports 0% taxes with or without this config parameter, always has. In fact, the config parameter has nothing to do with the tax percentage. However if you want a specific account move line with a zero value entry for a particular tax (whether it is 0% or 1000%), then you need that parameter set. Note that this behaviour is to the best of my knowledge not new, merely a work around because if taxes are computed externally they will initially be set to zero.But if you really need it, I would come up with a more accurate name, something like account_move_keep_zero_value_tax_linesOn Wed, May 21, 2025 at 5:17 PM Saran Limpajitkutaporn <notifications@odoo-community.org> wrote:Dear Community,In version 18, Odoo already supports creating 0% taxes via https://github.com/odoo/odoo/pull/199144but 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._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Graeme Gellatly - 11:51 - 21 May 2025 -
Re: Handling 0% Tax in Invoices
Hi Graeme,Thank you for your reply, and sorry for the misleading post.Yes, Odoo already supports 0% taxes,
but previously it didn’t add a tax line with 0 value, and there was no way to configure it.
Now, with this core improvement, it’s possible to hook into that behavior.I believe this kind of module would still be useful in OCA,
especially for countries (like mine) where showing 0% tax lines is required.I agree that the name should be more accurate — maybe account_move_keep_zero_tax_line would be better. What do you think?Thank you,Saran Lim.On Wed, May 21, 2025 at 12:47 PM Graeme Gellatly <notifications@odoo-community.org> wrote:Hi,This is a bit of a misleading post and module name. Odoo supports 0% taxes with or without this config parameter, always has. In fact, the config parameter has nothing to do with the tax percentage. However if you want a specific account move line with a zero value entry for a particular tax (whether it is 0% or 1000%), then you need that parameter set. Note that this behaviour is to the best of my knowledge not new, merely a work around because if taxes are computed externally they will initially be set to zero.But if you really need it, I would come up with a more accurate name, something like account_move_keep_zero_value_tax_linesOn Wed, May 21, 2025 at 5:17 PM Saran Limpajitkutaporn <notifications@odoo-community.org> wrote:Dear Community,In version 18, Odoo already supports creating 0% taxes via https://github.com/odoo/odoo/pull/199144but 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._______________________________________________
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 saranl - 08:56 - 21 May 2025 -
Re: Handling 0% Tax in Invoices
Hi,This is a bit of a misleading post and module name. Odoo supports 0% taxes with or without this config parameter, always has. In fact, the config parameter has nothing to do with the tax percentage. However if you want a specific account move line with a zero value entry for a particular tax (whether it is 0% or 1000%), then you need that parameter set. Note that this behaviour is to the best of my knowledge not new, merely a work around because if taxes are computed externally they will initially be set to zero.But if you really need it, I would come up with a more accurate name, something like account_move_keep_zero_value_tax_linesOn Wed, May 21, 2025 at 5:17 PM Saran Limpajitkutaporn <notifications@odoo-community.org> wrote:Dear Community,In version 18, Odoo already supports creating 0% taxes via https://github.com/odoo/odoo/pull/199144but 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.
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Graeme Gellatly - 07:46 - 21 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/199144but 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 -
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/1329I 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 -
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 -
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 4488hussain.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 -
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-analyzerThe script is just an initial idea — it takes the list of installed modules from a CSV and generates
.txtand.csvfiles 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 shellthat executes the necessary migration scripts for your project. After that, you perform anupdate allto 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 firstupdate 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 deMeesterDevelopment QAWilldooIT 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 versionI 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, removemigrationsfolder 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 AlomarCEO & Founder
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
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 - 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
-
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 deMeesterDevelopment QAWilldooIT 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 versionI 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, removemigrationsfolder 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 AlomarCEO & Founder
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by "Richard deMeester" <richard.demeester@willdooit.com> - 03:51 - 7 May 2025 - 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
-
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 -
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
digitalisierung & software
📍 Sonnendorf 33a, 6334 Schwoich | Austria
📞 +43 664 353 87 33 · 🌐 implema.at
by Matthias Ellmerer - 01:30 - 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, removemigrationsfolder 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 AlomarCEO & Founder
by Enric Tobella Alomar - 12:51 - 7 May 2025 - 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
