Archives
Contributors
contributors@odoo-community.org
-
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: 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
-
-
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 4488hussain.hammad@dexberts.com | www.dexberts.com
by hussain.hammad - 12:35 - 14 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
-
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 -
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, 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
by Stefan Rijnhart - 01:00 - 6 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 -
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
-
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, 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/
by Sébastien Alix - 12:26 - 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
-
-
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-
Re: SAAS solution
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,
Ivan Sokolov
Cetmix Odoo Solutionscetmix.com 
This message is sent using Mail Messages Easy app ----- Original message -----
Date: May 6, 2025, 4:53:15 AM
From: Notifications
Subject: SAAS solutionDear 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 INTERNACIONALT: +52 (800) 953-2012 #5200
M: +52 (442) 114-9164 | WhatsApp
C: MChambreuil@OpenSourceIntegrators.comAv. 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-
Re: Analytic info on inventory adjustments (Odoo 17)
🙂
Thanks!
MAXIME CHAMBREUIL
DIRECTOR INTERNACIONALT: +52 (800) 953-2012 #5200
M: +52 (442) 114-9164 | WhatsApp
C: MChambreuil@OpenSourceIntegrators.comAv. Antea 1032, Piso 4 Local 8, Colonia Jurica
Santiago de Querétaro, Querétaro, 76100, México
Analizar. Optimizar. Automatizar. Transicionar.
De: Roussel, Denis <notifications@odoo-community.org>
Enviado: lunes, 5 de mayo de 2025 13:37
Para: Contributors <contributors@odoo-community.org>
Asunto: Re: Analytic info on inventory adjustments (Odoo 17)
Le lun. 5 mai 2025, 20:57, Maxime Chambreuil <notifications@odoo-community.org> a écrit :
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 INTERNACIONALT: +52 (800) 953-2012 #5200
M: +52 (442) 114-9164 | WhatsApp
C: MChambreuil@OpenSourceIntegrators.com
Analizar. Optimizar. Automatizar. Transicionar.
_______________________________________________
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 Maxime Chambreuil - 10:31 - 5 May 2025 -
Re: Analytic info on inventory adjustments (Odoo 17)
Le lun. 5 mai 2025, 20:57, Maxime Chambreuil <notifications@odoo-community.org> a écrit :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 INTERNACIONALT: +52 (800) 953-2012 #5200
M: +52 (442) 114-9164 | WhatsApp
C: MChambreuil@OpenSourceIntegrators.com
Analizar. Optimizar. Automatizar. Transicionar.
_______________________________________________
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. - 09:33 - 5 May 2025
-
-
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.
by Denis Roussel. - 05:56 - 28 Apr 2025-
Re: Sale workflow repository v16
Thanks Daniel
Il 29/04/2025 09:31, Daniel Reis ha scritto:
A segunda, 28/04/2025, 23:22, Pedro M. Baeza <notifications@odoo-community.org> escreveu:
Thanks for doing this work._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
Security Notice: Don't be too quick to click!
Think carefully before clicking on links or attachments. Never provide your User ID or Passwords. Report any suspicious emails to your system administrator._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Antonio M. Vigliotti - 11:05 - 29 Apr 2025 -
Re: Sale workflow repository v16
Many thanks Denis!Sergio CoratoIl giorno mar 29 apr 2025 alle ore 10:28 Alex Comba <notifications@odoo-community.org> ha scritto:Thanks a lot!On Mon, Apr 28, 2025 at 5:57 PM Roussel, Denis <notifications@odoo-community.org> wrote: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._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Alex Comba
Tel (CH): +41 91 210 23 40_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Sergio Corato - 10:31 - 29 Apr 2025 -
Re: Sale workflow repository v16
Thanks a lot!On Mon, Apr 28, 2025 at 5:57 PM Roussel, Denis <notifications@odoo-community.org> wrote: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._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Alex Comba
Tel (CH): +41 91 210 23 40
by Alex Comba. - 10:20 - 29 Apr 2025 -
Re: Sale workflow repository v16
A segunda, 28/04/2025, 23:22, Pedro M. Baeza <notifications@odoo-community.org> escreveu:Thanks for doing this work._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
Security Notice: Don't be too quick to click!
Think carefully before clicking on links or attachments. Never provide your User ID or Passwords. Report any suspicious emails to your system administrator.
by Daniel Reis - 09:30 - 29 Apr 2025 -
Re: Sale workflow repository v16
Thanks for doing this work.
by Pedro M. Baeza - 12:21 - 29 Apr 2025
-
-
[Question] Preserve breadcrumb after page reload or reposition chatter dynamically
Hello everyone,
While working on an Odoo 17 project, I inherited the web_chatter_position module to add a button on form views that allows users to change the position of the chatter (either at the side or at the bottom of the form).
Currently, to make the position change effective, the button triggers a page reload, which unfortunately causes the breadcrumb to be lost.
My goal would be either:
• to preserve the breadcrumb after a reload (or restore it properly),
• or even better, to apply the chatter position change without reloading the page to keep a smooth UX.
I explored several approaches (dynamic JS manipulation, extending FormRenderer, etc.), but I haven’t found a satisfactory solution yet.
Would anyone know:
• of an existing community module that handles this use case?
• or of a clean technique to dynamically reposition the chatter without forcing a page reload?
Thank you very much in advance for your insights and suggestions!
Best regards,
Nazaire ADJAKOUN
ZENPILOTE
by Nazaire ADJAKOUN - 11:26 - 28 Apr 2025-
Re: [Question] Preserve breadcrumb after page reload or reposition chatter dynamically
Hello Tris,
Thank you very much for your quick reply!
I will take a closer look at the PR you mentioned.
Best regards,
Nazaire ADJAKOUNLe lun. 28 avr. 2025 à 10:53, Tris Doan <notifications@odoo-community.org> a écrit :On Mon, Apr 28, 2025 at 4:27 PM Dayo Sikiton Nazaire ADJAKOUN <notifications@odoo-community.org> wrote:Hello everyone,
While working on an Odoo 17 project, I inherited the web_chatter_position module to add a button on form views that allows users to change the position of the chatter (either at the side or at the bottom of the form).
Currently, to make the position change effective, the button triggers a page reload, which unfortunately causes the breadcrumb to be lost.
My goal would be either:
• to preserve the breadcrumb after a reload (or restore it properly),
• or even better, to apply the chatter position change without reloading the page to keep a smooth UX.
I explored several approaches (dynamic JS manipulation, extending FormRenderer, etc.), but I haven’t found a satisfactory solution yet.
Would anyone know:
• of an existing community module that handles this use case?
• or of a clean technique to dynamically reposition the chatter without forcing a page reload?
Thank you very much in advance for your insights and suggestions!
Best regards,
Nazaire ADJAKOUN
ZENPILOTE_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Nazaire ADJAKOUN - 12:55 - 28 Apr 2025 -
Re: [Question] Preserve breadcrumb after page reload or reposition chatter dynamically
On Mon, Apr 28, 2025 at 4:27 PM Dayo Sikiton Nazaire ADJAKOUN <notifications@odoo-community.org> wrote:Hello everyone,
While working on an Odoo 17 project, I inherited the web_chatter_position module to add a button on form views that allows users to change the position of the chatter (either at the side or at the bottom of the form).
Currently, to make the position change effective, the button triggers a page reload, which unfortunately causes the breadcrumb to be lost.
My goal would be either:
• to preserve the breadcrumb after a reload (or restore it properly),
• or even better, to apply the chatter position change without reloading the page to keep a smooth UX.
I explored several approaches (dynamic JS manipulation, extending FormRenderer, etc.), but I haven’t found a satisfactory solution yet.
Would anyone know:
• of an existing community module that handles this use case?
• or of a clean technique to dynamically reposition the chatter without forcing a page reload?
Thank you very much in advance for your insights and suggestions!
Best regards,
Nazaire ADJAKOUN
ZENPILOTE_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by doanminhtri8183 - 11:51 - 28 Apr 2025
-
-
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-
Re: Odoo Module Dependency Visualisation
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,
Ivan Sokolov
Cetmix Odoo Solutionscetmix.com 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 VisualisationHelloGreat 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.comLe 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
HelloGreat 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.comLe 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
-
-
Request for Community Input: Price List Assignment Behavior Change Between v13 and v17
Dear OCA Contributors, I hope this message finds you well. I’m writing to kindly draw your attention to an open issue in the [sale-workflow repository](https://github.com/OCA/sale-workflow/issues/3690) regarding a change in price list assignment behavior between Odoo v13 and v17. This issue affects clients who’ve migrated and rely on explicit partner-level price list configurations. Key Points for Awareness: - Behavior Change: The system now prioritizes Order Type-assigned price lists over direct partner settings (reversing v13 logic). - Impact: May lead to unintended pricing scenarios for migrated databases. - Documentation Gap: No migration notes or prior discussions were found about this change. How You Can Help: 1. Share Insights: If you’ve encountered this or know the rationale behind the change, please comment on the [GitHub issue thread](https://github.com/OCA/sale-workflow/issues/3690). 2. Reproduce: Verify the behavior in your environments (Runbot or local instances). 3. Suggest Solutions: Propose paths forward (e.g., restore v13 logic, add configurable priority). Why GitHub? To keep the discussion centralized and actionable, we’d appreciate all feedback directly on the issue thread. This ensures transparency and easier tracking for future reference. Thank you for your time and expertise! Let’s collaborate to find the best resolution for the community. Best regards, \rrebollo Binhex
by Ing. Rolando Pérez Rebollo - 03:31 - 25 Apr 2025 -
odoo/odoo 16.0 missing demo data Heisenbug alert!
Hello community,First please let's not forget we are fighting against bigger issues than just the 1% of OCA modules that depend on account_payment_order...And it happens that Odoo just broke the quiet Easter Peace and dropped one of their secret heisenbugs in the odoo/ooo repo, in the 16.0 branch (only in this branch). Since this change Friday https://github.com/odoo/odoo/pull/205695/files, modules with no dependencies or with auto_install: True will no longer get their beloved demo data installed!Their demo data might be simply missing or it might easily break the CI if dependent modules depend on these demo data (for their own demo data for instance)... I guess the laser eyes from Julien00859 just miss the issue...Proposed fix: https://github.com/odoo/odoo/pull/206767You might get the impression we are not doing much here in Brazil, but the bug and the fix has been discovered by Antonio Neto from Engenere here who would not be there if we didn't have this crazy Brazilian localization around... So kudos to him.--Raphaël ValyiFounder and consultant
by Raphaël Akretion - 10:16 - 20 Apr 2025-
Re: odoo/odoo 16.0 missing demo data Heisenbug alert!
In fact Antonio just told me the next oca-ci image daily build will be in a few hours, so the CI in a few 16.0 (like OCA/l10n-brazil) might still be broken meanwhile...On Tue, Apr 22, 2025 at 12:42 PM Virginie Dewulf <virginie@odoo-community.org> wrote:Good news.Thanks for sharing these bad then good news and for having spotted the issue together with Antonio Neto, Raphaël!Enjoy the rest of the week,Le mar. 22 avr. 2025 à 14:33, Raphaël Valyi <notifications@odoo-community.org> a écrit :FYI they reverted the bad commit today, si the regression is fixed: https://github.com/odoo/odoo/commit/a7201a9684c2f4724fe6b8560d69a1e21353f7efOn Sun, Apr 20, 2025 at 8:17 PM Raphaël Valyi <notifications@odoo-community.org> wrote:Hello community,First please let's not forget we are fighting against bigger issues than just the 1% of OCA modules that depend on account_payment_order...And it happens that Odoo just broke the quiet Easter Peace and dropped one of their secret heisenbugs in the odoo/ooo repo, in the 16.0 branch (only in this branch). Since this change Friday https://github.com/odoo/odoo/pull/205695/files, modules with no dependencies or with auto_install: True will no longer get their beloved demo data installed!Their demo data might be simply missing or it might easily break the CI if dependent modules depend on these demo data (for their own demo data for instance)... I guess the laser eyes from Julien00859 just miss the issue...Proposed fix: https://github.com/odoo/odoo/pull/206767You might get the impression we are not doing much here in Brazil, but the bug and the fix has been discovered by Antonio Neto from Engenere here who would not be there if we didn't have this crazy Brazilian localization around... So kudos to him.--Raphaël ValyiFounder and consultant_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Raphaël ValyiFounder and consultant_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Raphaël ValyiFounder and consultant
by Raphaël Akretion - 04:21 - 22 Apr 2025 -
Re: odoo/odoo 16.0 missing demo data Heisenbug alert!
Good news.Thanks for sharing these bad then good news and for having spotted the issue together with Antonio Neto, Raphaël!Enjoy the rest of the week,Le mar. 22 avr. 2025 à 14:33, Raphaël Valyi <notifications@odoo-community.org> a écrit :FYI they reverted the bad commit today, si the regression is fixed: https://github.com/odoo/odoo/commit/a7201a9684c2f4724fe6b8560d69a1e21353f7efOn Sun, Apr 20, 2025 at 8:17 PM Raphaël Valyi <notifications@odoo-community.org> wrote:Hello community,First please let's not forget we are fighting against bigger issues than just the 1% of OCA modules that depend on account_payment_order...And it happens that Odoo just broke the quiet Easter Peace and dropped one of their secret heisenbugs in the odoo/ooo repo, in the 16.0 branch (only in this branch). Since this change Friday https://github.com/odoo/odoo/pull/205695/files, modules with no dependencies or with auto_install: True will no longer get their beloved demo data installed!Their demo data might be simply missing or it might easily break the CI if dependent modules depend on these demo data (for their own demo data for instance)... I guess the laser eyes from Julien00859 just miss the issue...Proposed fix: https://github.com/odoo/odoo/pull/206767You might get the impression we are not doing much here in Brazil, but the bug and the fix has been discovered by Antonio Neto from Engenere here who would not be there if we didn't have this crazy Brazilian localization around... So kudos to him.--Raphaël ValyiFounder and consultant_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Raphaël ValyiFounder and consultant_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Virginie Dewulf (OCA) - 02:41 - 22 Apr 2025 -
Re: odoo/odoo 16.0 missing demo data Heisenbug alert!
FYI they reverted the bad commit today, si the regression is fixed: https://github.com/odoo/odoo/commit/a7201a9684c2f4724fe6b8560d69a1e21353f7efOn Sun, Apr 20, 2025 at 8:17 PM Raphaël Valyi <notifications@odoo-community.org> wrote:Hello community,First please let's not forget we are fighting against bigger issues than just the 1% of OCA modules that depend on account_payment_order...And it happens that Odoo just broke the quiet Easter Peace and dropped one of their secret heisenbugs in the odoo/ooo repo, in the 16.0 branch (only in this branch). Since this change Friday https://github.com/odoo/odoo/pull/205695/files, modules with no dependencies or with auto_install: True will no longer get their beloved demo data installed!Their demo data might be simply missing or it might easily break the CI if dependent modules depend on these demo data (for their own demo data for instance)... I guess the laser eyes from Julien00859 just miss the issue...Proposed fix: https://github.com/odoo/odoo/pull/206767You might get the impression we are not doing much here in Brazil, but the bug and the fix has been discovered by Antonio Neto from Engenere here who would not be there if we didn't have this crazy Brazilian localization around... So kudos to him.--Raphaël ValyiFounder and consultant_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--Raphaël ValyiFounder and consultant
by Raphaël Akretion - 02:31 - 22 Apr 2025
-
-
BI and reporting tools
Hi,
I am researching different ways to do BI (business intelligence) and reporting with Odoo.
I am wondering whether it's worth it to invest on an external BI tool connected to the Odoo database.
On the community version I have the impression that the standard BI tools (standard pivot and graphs reports in Odoo) are sometimes limited in terms of performance (it's slow for wide and long pivot tables), data visualization (standard charts are not very useful) and flexibility (hard to make computations).
I know of the bi_view_editor and bi_sql_editor modules. Both are very useful and greatly extends the standard reports. But the limits listed above remains. But it seems it's hard to use it as is, in my case I always have to export manually the tables to build the table or chart I want with excel.
I also know of the spreadsheet and dashboard modules, although I don't have a great experience with it. Maybe it provides the lacking flexibility mentioned above ?
The last option is to connect a BI tool (Tableau, PowerBI, Apache superset, Metabase...) to the database. The main advantage is to connect it to other sources of data. But I am wondering if it's still worth it even connected only to the Odoo database.
Do you use an external BI tools ? If yes, which one seems to work well with Odoo (and preferably open source) ?
If no, how do you deal with BI and reporting for your clients ? Are you also confronted to performance issues, lack of flexibility and poor library of charts ?
Thank you for your inputs !
-- Victor Champonnois - Coop IT Easy
by Victor Champonnois - 10:32 - 16 Apr 2025-
Re: AW: BI and reporting tools
Hi all,I have tested the metabase on my laptop. It does the job but in the context of an odoo database with a lot of tables and data,it seems it consumes a lot of memory (really really a lot).Probably there are in this video more innovative ways to build an BI tools.Yes BI requires it to be managed with traceability. Changes should be reverted if necessary.Personally I have succinctly used odoo shiny spreadsheets with a lot of frustrations :-( . Is there somebody who seriously uses it ?I plan to invest in solutions from this video : https://evidence.dev markdown + sql sounds great.Marimo could also be a solution in future iterations.I'm interested in your feedback in this field. Thanksmy 2 ctsRegardsLe jeu. 17 avr. 2025 à 16:12, Joel Patrick <notifications@odoo-community.org> a écrit :I am interested in using BI to help with decision-making on in-process inventory. There are industrial processes where materials are kept in process for a period of time to all maturation (winemaking, food processing, crystal growing, and many other things. Sometimes you can use a very deterministic recipe, but more often than not, you have a range of outcomes to plan for. I would like to use the Odoo data record (registered in Mfg Orders) to build a body of knowledge linked to history by product and product family to help users manage rough cut planning and refine recipes. Ultimately, I would like to use the past MO data for analysis and as a reference in real time. This was a hot topic for leveraging SAP HANA, but I left the SAP ecosystem before I could see that in practice (to the extent that something happened with the idea.)I like the idea of putting the datasets in Postgres since most of my implementations are quite small-scale, and I am thinking it would be easier to reuse a focused decision-support dataset via an Odoo custom model.Any thoughts?On Thu, Apr 17, 2025 at 5:38 AM Victor Champonnois <notifications@odoo-community.org> wrote:Thank you for your replies, I will have a look at Metabase.
Thank you also for the tips about foreign data wrapper and Metabase models. Real time reporting is indeed an important feature.
Have a nice day,
Victor Champonnois - Coop IT Easy
On 16/04/25 10:47, David Brühlmeier wrote:
Hi Victor,
We are using Metabase (self-hosted) and are very happy with it so far. The main advantage IMHO is the possibility to connect data from Odoo with data from other data sources. The main disadvantage is the potential complexity of the Odoo data model. To address this, we are providing Models in Metabase for all the main business objects or our end users.
In terms of architecture we have decided to use Metabase without an ETL layer. Metabase connects only to one database (because it's currently not possible to make joins in Metabase from different databases). This database is a dedicated Postgres instance, which uses FDW (Foreign Data Wrapper) to connect to the source databases, such as Odoo. This approach has the advantage of realtime reporting and also reducing complexity because we don't need an ETL process. In terms of performance, it's good enough so far. Should we run into issues, we might add a read-replica as a secondary database for our source applications.
Hope this helps!Dave
Von: Victor Champonnois <notifications@odoo-community.org>
Gesendet: Mittwoch, 16. April 2025 10:32
An: Contributors <contributors@odoo-community.org>
Betreff: BI and reporting toolsHi,
I am researching different ways to do BI (business intelligence) and reporting with Odoo.
I am wondering whether it's worth it to invest on an external BI tool connected to the Odoo database.
On the community version I have the impression that the standard BI tools (standard pivot and graphs reports in Odoo) are sometimes limited in terms of performance (it's slow for wide and long pivot tables), data visualization (standard charts are not very useful) and flexibility (hard to make computations).
I know of the bi_view_editor and bi_sql_editor modules. Both are very useful and greatly extends the standard reports. But the limits listed above remains. But it seems it's hard to use it as is, in my case I always have to export manually the tables to build the table or chart I want with excel.
I also know of the spreadsheet and dashboard modules, although I don't have a great experience with it. Maybe it provides the lacking flexibility mentioned above ?
The last option is to connect a BI tool (Tableau, PowerBI, Apache superset, Metabase...) to the database. The main advantage is to connect it to other sources of data. But I am wondering if it's still worth it even connected only to the Odoo database.
Do you use an external BI tools ? If yes, which one seems to work well with Odoo (and preferably open source) ?
If no, how do you deal with BI and reporting for your clients ? Are you also confronted to performance issues, lack of flexibility and poor library of charts ?
Thank you for your inputs !
-- Victor Champonnois - Coop IT Easy_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by David BEAL - 01:20 - 28 Apr 2025 -
Re: AW: BI and reporting tools
Thank you for your replies, I will have a look at Metabase.
Thank you also for the tips about foreign data wrapper and Metabase models. Real time reporting is indeed an important feature.
Have a nice day,
Victor Champonnois - Coop IT Easy
On 16/04/25 10:47, David Brühlmeier wrote:
Hi Victor,
We are using Metabase (self-hosted) and are very happy with it so far. The main advantage IMHO is the possibility to connect data from Odoo with data from other data sources. The main disadvantage is the potential complexity of the Odoo data model. To address this, we are providing Models in Metabase for all the main business objects or our end users.
In terms of architecture we have decided to use Metabase without an ETL layer. Metabase connects only to one database (because it's currently not possible to make joins in Metabase from different databases). This database is a dedicated Postgres instance, which uses FDW (Foreign Data Wrapper) to connect to the source databases, such as Odoo. This approach has the advantage of realtime reporting and also reducing complexity because we don't need an ETL process. In terms of performance, it's good enough so far. Should we run into issues, we might add a read-replica as a secondary database for our source applications.
Hope this helps!Dave
Von: Victor Champonnois <notifications@odoo-community.org>
Gesendet: Mittwoch, 16. April 2025 10:32
An: Contributors <contributors@odoo-community.org>
Betreff: BI and reporting toolsHi,
I am researching different ways to do BI (business intelligence) and reporting with Odoo.
I am wondering whether it's worth it to invest on an external BI tool connected to the Odoo database.
On the community version I have the impression that the standard BI tools (standard pivot and graphs reports in Odoo) are sometimes limited in terms of performance (it's slow for wide and long pivot tables), data visualization (standard charts are not very useful) and flexibility (hard to make computations).
I know of the bi_view_editor and bi_sql_editor modules. Both are very useful and greatly extends the standard reports. But the limits listed above remains. But it seems it's hard to use it as is, in my case I always have to export manually the tables to build the table or chart I want with excel.
I also know of the spreadsheet and dashboard modules, although I don't have a great experience with it. Maybe it provides the lacking flexibility mentioned above ?
The last option is to connect a BI tool (Tableau, PowerBI, Apache superset, Metabase...) to the database. The main advantage is to connect it to other sources of data. But I am wondering if it's still worth it even connected only to the Odoo database.
Do you use an external BI tools ? If yes, which one seems to work well with Odoo (and preferably open source) ?
If no, how do you deal with BI and reporting for your clients ? Are you also confronted to performance issues, lack of flexibility and poor library of charts ?
Thank you for your inputs !
-- Victor Champonnois - Coop IT Easy_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Victor Champonnois - 11:36 - 17 Apr 2025 -
Re: AW: BI and reporting tools
We also Use Metabase for some of our projects, which works nicely.
We do a daily replication of the database, to not disturb operations, and provide end users with pre defined models for the Odoo database.
Op 16-04-2025 om 10:47 schreef David Brühlmeier:
In terms of architecture we have decided to use Metabase without an ETL layer. Metabase connects only to one database (because it's currently not possible to make joins in Metabase from different databases). This database is a dedicated Postgres instance, which uses FDW (Foreign Data Wrapper) to connect to the source databases, such as Odoo. This approach has the advantage of realtime reporting and also reducing complexity because we don't need an ETL process. In terms of performance, it's good enough so far. Should we run into issues, we might add a read-replica as a secondary database for our source applications.
--
Met vriendelijke groet - Kind Regards - Mit freundlichen Grüßen,
Thomas Pot
Open2Bizz B.V. dé Odoo specialist
https://www.open2bizz.nl
https://care-software.com
Mauritslaan 56 | 6161 HW | Geleen (NL)
Maak meteen een afspraak voor een online demo van Odoo / Care-Software:
klik hier
LinkedIn Connectie maken
by Thomas Pot - 12:21 - 16 Apr 2025
-
-
Odoo14: increment time precision for BoM operations
Hi,We have a customer who needs a better precision for the "Duration" field of the BoM operations.By default this field is handled with a precision of 1.0 seconds, so if you produce a single unit in, for example, 1.44 seconds, the overall production time cannot be properly estimated as you can only round by 1 second or 2 seconds.Do you have any recommendations on how to effectively handle this scenario?Thanks--Francesco Ballerini
by Francesco Ballerini - 11:37 - 14 Apr 2025-
Re: Odoo14: increment time precision for BoM operations
Hi JacobI found a similar but slightly better solution by extending this nice module https://apps.odoo.com/apps/modules/14.0/crnd_web_float_full_time_widget which provide an enhanced float_time widget and allows to set milliseconds on it.. then inherited a couple of views, so the datas on GUI can be filled / presented in milliseconds.. we're waiting for the customer validation, didn't find a better solution yet, but this might be enough I hope.I appreciate your help, regards--FrancescoIl giorno lun 14 apr 2025 alle ore 18:52 Jacob Christ <notifications@odoo-community.org> ha scritto:I don't know how this is used downstream in Odoo but could you just assume that the field is in millisecond and just dividing any totals by 1000 later on? Manual and yucky but it might be helpful until a better solution presents itself.Jacob Christ
+1 (714) 269-7256 CellOn Mon, Apr 14, 2025, 2:39 AM Francesco Ballerini <notifications@odoo-community.org> wrote:Hi,We have a customer who needs a better precision for the "Duration" field of the BoM operations.By default this field is handled with a precision of 1.0 seconds, so if you produce a single unit in, for example, 1.44 seconds, the overall production time cannot be properly estimated as you can only round by 1 second or 2 seconds.Do you have any recommendations on how to effectively handle this scenario?Thanks--Francesco Ballerini_______________________________________________
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 Francesco Ballerini - 08:56 - 14 Apr 2025
-
-
Follow-up for specific product e-Commerce
Dear Odoo Community Contributors,I hope this message finds you well.I'm currently working on an automation for my e-commerce based on Odoo, and I would like some guidance regarding the best approach to achieve it.My goal is to trigger the sending of a specific email upon the purchase of a particular product. Ideally, each product should have its own tailored email sent to the customer after the purchase is confirmed. I was considering using the Marketing Automation module to implement this workflow, but I’m open to alternative solutions if there is a more appropriate or efficient way to achieve this result.Could you kindly advise on the best practice or point me towards existing modules or community projects that might help?Thank you very much in advance for your support and the amazing work you all do!
Best Regards,
Marco Morra
Founder
Digisolve di Morra Marco
Mobile / +39 329 112 6861
Email / marco.morra@digisolve.it
Sito web / www.digisolve.it
by "Marco Morra" <marco.morra@digisolve.it> - 03:16 - 11 Apr 2025-
Re: Follow-up for specific product e-Commerce
Dear Marco,
Isn't your need covered by native product_email_template module ?
<https://github.com/odoo/odoo/tree/18.0/addons/product_email_template>
Best Regards,
RémiLe 11 avril 2025 13:18:02 UTC, Marco Morra <notifications@odoo-community.org> a écrit :Dear Odoo Community Contributors,I hope this message finds you well.I'm currently working on an automation for my e-commerce based on Odoo, and I would like some guidance regarding the best approach to achieve it.My goal is to trigger the sending of a specific email upon the purchase of a particular product. Ideally, each product should have its own tailored email sent to the customer after the purchase is confirmed. I was considering using the Marketing Automation module to implement this workflow, but I’m open to alternative solutions if there is a more appropriate or efficient way to achieve this result.Could you kindly advise on the best practice or point me towards existing modules or community projects that might help?Thank you very much in advance for your support and the amazing work you all do!
Best Regards,
Marco Morra
Founder
Digisolve di Morra Marco
Mobile / +39 329 112 6861
Email / marco.morra@digisolve.it
Sito web / www.digisolve.it_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Rémi Cazenave - 07:55 - 11 Apr 2025 -
Re: Follow-up for specific product e-Commerce
Hi Marco,For that type of automations we use this for our processes and implementations:Hope it helps,BestOn Fri, Apr 11, 2025 at 2:18 PM Marco Morra <notifications@odoo-community.org> wrote:Dear Odoo Community Contributors,I hope this message finds you well.I'm currently working on an automation for my e-commerce based on Odoo, and I would like some guidance regarding the best approach to achieve it.My goal is to trigger the sending of a specific email upon the purchase of a particular product. Ideally, each product should have its own tailored email sent to the customer after the purchase is confirmed. I was considering using the Marketing Automation module to implement this workflow, but I’m open to alternative solutions if there is a more appropriate or efficient way to achieve this result.Could you kindly advise on the best practice or point me towards existing modules or community projects that might help?Thank you very much in advance for your support and the amazing work you all do!
Best Regards,
Marco Morra
Founder
Digisolve di Morra Marco
Mobile / +39 329 112 6861
Email / marco.morra@digisolve.it
Sito web / www.digisolve.it_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
--
Jorge Elena Poblet
Founder & CEO
Binhex
j.elena@binhex.cloud
Office (Spain) : +34 622 40 08 08
Office (USA): +1 561 403 4406Offices:
Miami | 8325 NE 2nd Ave, Miami, FL 33138, United States
Texas | 27027 Westheimer Pkwy Katy, TX 77494, United States
Tenerife | Street Subida al Mayorazgo, 13, Office 15-2
Las Palmas | Edificio Polivalente IV Campus de Tafira Parque Tecnológico de Gran Canaria
Start for free: Try Odoo Community in the cloud This email is confidential and intended only for the recipient. If you are not the intended recipient, please notify the sender and delete it immediately.
Privacy Policy
by Jorge Elena Poblet - 03:30 - 11 Apr 2025
-
No upstream merges in OCB in April
It looks like OCB hasn't merged remote-tracking branches for a while (no merges so far in April). Is something clogging the process? Some of our OCA PRs are affected by this, since the fix in Odoo hasn't yet reached OCB.--Yoshi TashiroQuartile
by Yoshi Tashiro - 03:21 - 10 Apr 2025-
Re: No upstream merges in OCB in April
Yes, the conflict on 17.0 was the cause.Best regards,-StéphaneOn Mon, Aug 4, 2025 at 5:37 PM Pedro M. Baeza <notifications@odoo-community.org> wrote:I have manually synchronized 16.0 and 17.0 branches.There was a conflict in the 17.0 branch, and this may abort the rest of the sync I suppose.Regards._______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Stéphane Bidoul - 06:21 - 4 Aug 2025 -
Re: No upstream merges in OCB in April
I have manually synchronized 16.0 and 17.0 branches.There was a conflict in the 17.0 branch, and this may abort the rest of the sync I suppose.Regards.
by Pedro M. Baeza - 05:36 - 4 Aug 2025 -
Re: No upstream merges in OCB in April
Awesome. Thank you very much, Pedro and Denis!--Yoshi TashiroQuartileOn Fri, Apr 11, 2025 at 4:07 PM Pedro M. Baeza <notifications@odoo-community.org> wrote:Hi, Yoshi,There was a change upstream in README.md that conflicts with OCB, as detected by Denis in https://github.com/OCA/OCB/pull/1293#issuecomment-2796016633. I have pulled locally and fix the conflict, pushing the result, and it should return to normal synchronization.Thanks for noticing.
_______________________________________________
Mailing-List: https://odoo-community.org/groups/contributors-15
Post to: mailto:contributors@odoo-community.org
Unsubscribe: https://odoo-community.org/groups?unsubscribe
by Yoshi Tashiro - 10:51 - 11 Apr 2025 -
Re: No upstream merges in OCB in April
Hi, Yoshi,There was a change upstream in README.md that conflicts with OCB, as detected by Denis in https://github.com/OCA/OCB/pull/1293#issuecomment-2796016633. I have pulled locally and fix the conflict, pushing the result, and it should return to normal synchronization.Thanks for noticing.
by Pedro M. Baeza - 09:06 - 11 Apr 2025
-
-
Swiss long term real estate
Hello, I have a prospect focus in long term real estate administration based in Switzerland. we have a law that requires the distribution of some costs such as gas, elevators, etc. based on various factors. An example is heating where a state table is imposed divided into months with January 18.20% of the annual cost, February 14.80%, etc. . What I am looking for is a form that offers the possibility of dividing the annual amount of heating costs based on the months. Do you have any ideas? -- Stefano Sforzi Tel (CH): +41 91 210 23 40 Tel (IT): +39 0331 158 7090 https://www.agilebg.com
by stefano sforzi - 04:41 - 9 Apr 2025-
Re: Swiss long term real estate
Hi Pierre thanks a lot for your answer but what we need is a little bit different
The usecase is this:
1) we receive the invoice (one or more) from the gas provider for the entire building (and the same for light and so on)
2) at the end of the year, we need to split the gas amount to the single apartment based of the months occupied but the single month have different weight (January 18.20% of the annual cost, February 14.80%, etc.)
3) we need to split a lot of buildings with a lot of apartments
Any ideas?
Thanks
Il 09.04.2025 17:07, Pierre Verkest ha scritto:
Hi Stefano,
It's not clear to me if your cost come from a supplier invoice or something else, from accounting perspective, I've the feeling you are speaking of cutoff features to spread expenses over the entire fiscal period - I'm not an accounting and I've never works on switzerland -, I've implement something based on prorata temporis in account_move_cutoff (module presented at last OCA days https://www.youtube.com/watch?v=7N39fjX0nBs) that I'm currently porting to v17.0.
We have already 2 distribution methods, you could add a new one if needed.
hope this helps,
Le mer. 9 avr. 2025 à 16:42, Stefano Sforzi <notifications@odoo-community.org> a écrit :
Hello, I have a prospect focus in long term real estate administration based in Switzerland. we have a law that requires the distribution of some costs such as gas, elevators, etc. based on various factors. An example is heating where a state table is imposed divided into months with January 18.20% of the annual cost, February 14.80%, etc. . What I am looking for is a form that offers the possibility of dividing the annual amount of heating costs based on the months. Do you have any ideas? -- Stefano Sforzi Tel (CH): +41 91 210 23 40 Tel (IT): +39 0331 158 7090 https://www.agilebg.com_______________________________________________
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
-- Tel (CH): +41 91 210 23 40 Tel (IT): +39 011 198 25481 http://www.agilebg.com
by Agile Business Group Sagl - 12:11 - 14 Apr 2025 -
Re: Swiss long term real estate
Hi Stefano,It's not clear to me if your cost come from a supplier invoice or something else, from accounting perspective, I've the feeling you are speaking of cutoff features to spread expenses over the entire fiscal period - I'm not an accounting and I've never works on switzerland -, I've implement something based on prorata temporis in account_move_cutoff (module presented at last OCA days https://www.youtube.com/watch?v=7N39fjX0nBs) that I'm currently porting to v17.0.We have already 2 distribution methods, you could add a new one if needed.hope this helps,Le mer. 9 avr. 2025 à 16:42, Stefano Sforzi <notifications@odoo-community.org> a écrit :Hello, I have a prospect focus in long term real estate administration based in Switzerland. we have a law that requires the distribution of some costs such as gas, elevators, etc. based on various factors. An example is heating where a state table is imposed divided into months with January 18.20% of the annual cost, February 14.80%, etc. . What I am looking for is a form that offers the possibility of dividing the annual amount of heating costs based on the months. Do you have any ideas? -- Stefano Sforzi Tel (CH): +41 91 210 23 40 Tel (IT): +39 0331 158 7090 https://www.agilebg.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 Pierre Verkest - 05:06 - 9 Apr 2025
-
