Odoo Changelog — 2025-03-11

Tuesday, March 11, 2025

7 changes · 17.0

Bug Fixes(7)

Resolved issues and error corrections

[FIX] web: many2many_tags: no crash when quickly remove tags

PR #201164

Core17.0webMedium

Fixed an issue where quickly pressing Backspace to remove multiple tags could cause forms to crash or process the same removal more than once. This makes tag-heavy fields more reliable, especially when the connection or server response is slower.

Original PR description

Have a many2many_tags field, in a form view for instance, with multiple tags. Focus its input, and then quickly press `Backspace` multiple times. Before this commit, there were 2 problems.

First, if there was an onchange on that field, the onchange was triggered multiple times with the same forget command, especially on a slow-ish network.

Second, there could be a crash, but to reproduce it the timing had to be precise: backspace should have been pressed when a previous tag deletion was already processed by the model (i.e. the tag is no longer in the list), but the DOM wasn't updated yet. This could be done more easily then it sounds, by quickly pressing backspace on a many2many_tags with a lot of tags.

The related opw is about the second issue, as the first one isn't obversable functionally. However, testing the second one is really tricky, even impossible without going white-box. We thus wrote a test for the first issue only, as the fix for both is actually the same.

opw-4596936

#many2many_tags#stability#forms

[REV] website_sale: remove overridden of _getRpcParameters as it is not used and give warning on the log

PR #201158

Core17.0website_saleMedium

This change restores data needed by webshop product snippets so related product sections can load the right items. It fixes accessories, recently sold, and alternative product suggestions that may otherwise show incorrect or missing results.

Original PR description

This reverts commit aef59e06d8d0ba388cd781fd9a9511d6ff74ea05.

It was wrongly assumed that `_getRpcParameters` was useless in `s_dynamic_snippet_products`. It adds a parameter  `productTemplateId` to the request to `/website/snippet/filters` which is used by `ir.actions.server`:
- `dynamic_snippet_accessories_action`,
- `dynamic_snippet_recently_sold_with_action`,
- `dynamic_snippet_alternative_products`.

#ecommerce#product-recommendations#website

[FIX] l10n_it_edi: the dispatching of negative lines was wrong

PR #199100

Core17.0l10n_it_ediMedium

Italian electronic invoices no longer automatically treat negative invoice lines as discounts. This avoids confusing or incorrect invoice exports for businesses that use negative lines for other purposes, while keeping expected XML outputs covered by tests.

Original PR description

Feedbacks given talked about the fact the negative lines were wrong and should be considered as discounts.
But that's not the case for every user and is more confusing than anything else.
So we remove this logic from Italy.




---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#italy#e-invoicing#invoicing#negative-lines

[FIX] account_payment: avoid locking when posting journal entries

PR #199438

Core17.0accountaccount_paymentpos_online_paymentMedium

This fix changes how payments and journal entries are processed so concurrent orders are less likely to block each other in the database. It helps prevent slowdowns or deadlocks during high-volume events while preserving legally required accounting numbering rules.

Original PR description

Issue ===== When multiple orders are being made at the same time and paid at the same time, for instance for a blitz ticket sale, we encountered congestion on the database. Investigation…

Issue
=====

When multiple orders are being made at the same time and paid at the same time, for instance for a blitz ticket sale, we encountered congestion on the database.

Investigation
=============

The locking is done because of a postgres constraint on `account_move` (`account_move_unique_name`). This lock is released as soon as the other transaction is locked.
This locking is necessary to ensure that no gaps are made when numbering the journal entries, for legal reasons.

There are multiple causes possible:
* The transactions are open for too long after the locking has been made. This can be reduced by pushing the posting of the journal entries as for as possible to the end of the transaction. Most of the work done after posting the invoices is creating, posting, and reconciling the payments. Creating the payment can easily be move before posting anything.
* Posting moves in different journals can cause a deadlock if the order of the journal is not always the same. It was actually the case in `_reconcile_after_done`:
  * first all the invoices related to the transaction (`invoice_ids`) were posted (journal A)
  * then the payments were created and posted (journal B)
  * then, in case there was a source transaction, we were posting other invoices (`source_transaction_id.invoice_ids`) This could lead to:
  * one transaction having acquired the lock on the invoice journal, then waiting for the lock on the payment journal (posting invoice first)
  * another transaction having acquired the lock on the payment journal, then waiting on the lock on the invoice journal (creating and posting the payment first)

Solution
========

For the first issue, simply create the payments before posting anything.

For the second issue, we can post everything at the same time. This will lead to let `<account.move>.action_post` determine the order. This order is the first post payments, the the other moves. And the orders in each group is now determined by the journal's id.

Using the same approach (posting everything at once using only one call to `action_post`) should be enough to prevent any deadlock due to this constraint.

[FIX] stock: prevent error while printing report

PR #198796

Core17.0stockMedium

This fixes a failure that could happen when printing inventory receipt documents after the related Picking Operations report action was deleted. The system now prevents that essential report setup from being removed and shows a clear user-facing error if it is already missing, helping users avoid an unexpected crash during warehouse operations.

Original PR description

This error occurs when user deletes the Picking Operations action.

Steps to Reproduce :

- Install the `Stock` module.
- Navigate to Settings > Technical > Actions.
- Search for `Picking Operations` in the list of actions.
- Delete the `Picking Operations` action.
- Go to Inventory > Operations and open any `Receipt`.
- Click on the `Print` button.

ValueError: External ID not found in the system: stock.action_report_picking

This error occurs when the system attempts to access the Picking Operations action, but it has been deleted.

To resolve this issue, restrict the deletion of the `Picking Operations` report from the `ir actions`, to ensure that users cannot delete it (except during the module uninstallation), and also raise a user error for already existing DBs where `Picking Operations` has been deleted.

Sentry - 6302556324

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#inventory#printing#reports#receipts

[FIX] analytic: enable proper search on analytic distribution

PR #200931

Core17.0analyticMedium

Users can once again filter records by analytic distribution in areas that use analytic accounting, such as purchase order lines. This restores a missing search option, making it easier to find and review transactions tied to specific analytic accounts.

Original PR description

Currently, in models with the analytic mixin, users are not able to filter records by analytic distribution.

Steps to reproduce:
- Enable analytic accounting
- Create a Purchase order, having analytic distribution set on a line
- In list view filter by [Add Custom Filter] for Order Lines > Analytic Distribution

Issue: Mentioned filter cannot be found. It was removed in https://github.com/odoo/odoo/pull/195765
Now users have no way to filter records by analytic distribution.

This commit backport the `distribution_analytic_account_ids` field introduced in 18.0 [1] in order to properly search analytic accounts

[1] https://github.com/odoo/odoo/commit/381f201d49626bdd22c1f0b10d7050df0d264714

opw-4620169

#analytic accounting#search#filters

[FIX] project_enterprise: show gantt without stages enabled

PR #79968

Enterprise17.0project_enterpriseMedium

Fixes an error that prevented users from opening or enabling the Project Gantt view when the Project Stages setting was turned off. This lets teams use Gantt planning in Projects without requiring stage-based workflows.

Original PR description

**Issue** The project's Gantt view doesn't work if the "Project Stages" setting is not enabled. **Steps to reproduce** - Install `project_enterprise` and Studio. - Have project stages disabled. -…

**Issue**
The project's Gantt view doesn't work if the "Project Stages"
setting is not enabled.

**Steps to reproduce**
- Install `project_enterprise` and Studio.
- Have project stages disabled.
- Open Projects app.
- Click on Studio button > Views > Try to activate Gantt view.
-> `AccessError for read on stage_id`

**Cause**
The `stage_id` field used on the project gantt view is only readable if
the project stages feature is enabled.
https://github.com/odoo/enterprise/blob/b911ed1e857e1534c86495cd4934c1adb8ae9597/project_enterprise/views/project_views.xml#L12

**Solution**
A hack is to add in the model metadata the `colorField` key used by the
gantt renderer to color the pills:
https://github.com/odoo/enterprise/blob/28f2fba988b1b225c97d15729020962ed4dee73b/web_gantt/static/src/gantt_renderer.js#L778
It is normally set when parsing the view here:
https://github.com/odoo/enterprise/blob/dfe2795b820527a8226d8cf1afa5bf7ac8fcb53d/web_gantt/static/src/gantt_arch_parser.js#L194
This avoids trying to read the field if the user doesn't have the
necessary `project.group_project_stages` group.

Note: some missing views are also added in this commit, they were missing
when the project stage feature wasn't enabled.

opw-4592110

Have a many2many_tags field, in a form view for instance, with multiple tags. Focus its input, and then quickly press `Backspace` multiple times. Before this commit, there were 2 problems. First, if there was an onchange on that field, the onchange was triggered multiple times with the same forget command, especially on a slow-ish network. Second, there could be a crash, but to reproduce it the timing had to be precise: backspace should have been pressed when a previous tag deletion was already processed by the model (i.e. the tag is no longer in the list), but the DOM wasn't updated yet. This could be done more easily then it sounds, by quickly pressing backspace on a many2many_tags with a lot of tags. The related opw is about the second issue, as the first one isn't obversable functionally. However, testing the second one is really tricky, even impossible without going white-box. We thus wrote a test for the first issue only, as the fix for both is actually the same. opw-4596936

This reverts commit aef59e06d8d0ba388cd781fd9a9511d6ff74ea05. It was wrongly assumed that `_getRpcParameters` was useless in `s_dynamic_snippet_products`. It adds a parameter `productTemplateId` to the request to `/website/snippet/filters` which is used by `ir.actions.server`: - `dynamic_snippet_accessories_action`, - `dynamic_snippet_recently_sold_with_action`, - `dynamic_snippet_alternative_products`.

Feedbacks given talked about the fact the negative lines were wrong and should be considered as discounts. But that's not the case for every user and is more confusing than anything else. So we remove this logic from Italy. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Issue ===== When multiple orders are being made at the same time and paid at the same time, for instance for a blitz ticket sale, we encountered congestion on the database. Investigation ============= The locking is done because of a postgres constraint on `account_move` (`account_move_unique_name`). This lock is released as soon as the other transaction is locked. This locking is necessary to ensure that no gaps are made when numbering the journal entries, for legal reasons. There are multiple causes possible: * The transactions are open for too long after the locking has been made. This can be reduced by pushing the posting of the journal entries as for as possible to the end of the transaction. Most of the work done after posting the invoices is creating, posting, and reconciling the payments. Creating the payment can easily be move before posting anything. * Posting moves in different journals can cause a deadlock if the order of the journal is not always the same. It was actually the case in `_reconcile_after_done`: * first all the invoices related to the transaction (`invoice_ids`) were posted (journal A) * then the payments were created and posted (journal B) * then, in case there was a source transaction, we were posting other invoices (`source_transaction_id.invoice_ids`) This could lead to: * one transaction having acquired the lock on the invoice journal, then waiting for the lock on the payment journal (posting invoice first) * another transaction having acquired the lock on the payment journal, then waiting on the lock on the invoice journal (creating and posting the payment first) Solution ======== For the first issue, simply create the payments before posting anything. For the second issue, we can post everything at the same time. This will lead to let `<account.move>.action_post` determine the order. This order is the first post payments, the the other moves. And the orders in each group is now determined by the journal's id. Using the same approach (posting everything at once using only one call to `action_post`) should be enough to prevent any deadlock due to this constraint.

This error occurs when user deletes the Picking Operations action. Steps to Reproduce : - Install the `Stock` module. - Navigate to Settings > Technical > Actions. - Search for `Picking Operations` in the list of actions. - Delete the `Picking Operations` action. - Go to Inventory > Operations and open any `Receipt`. - Click on the `Print` button. ValueError: External ID not found in the system: stock.action_report_picking This error occurs when the system attempts to access the Picking Operations action, but it has been deleted. To resolve this issue, restrict the deletion of the `Picking Operations` report from the `ir actions`, to ensure that users cannot delete it (except during the module uninstallation), and also raise a user error for already existing DBs where `Picking Operations` has been deleted. Sentry - 6302556324 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Currently, in models with the analytic mixin, users are not able to filter records by analytic distribution. Steps to reproduce: - Enable analytic accounting - Create a Purchase order, having analytic distribution set on a line - In list view filter by [Add Custom Filter] for Order Lines > Analytic Distribution Issue: Mentioned filter cannot be found. It was removed in https://github.com/odoo/odoo/pull/195765 Now users have no way to filter records by analytic distribution. This commit backport the `distribution_analytic_account_ids` field introduced in 18.0 [1] in order to properly search analytic accounts [1] https://github.com/odoo/odoo/commit/381f201d49626bdd22c1f0b10d7050df0d264714 opw-4620169

**Issue** The project's Gantt view doesn't work if the "Project Stages" setting is not enabled. **Steps to reproduce** - Install `project_enterprise` and Studio. - Have project stages disabled. - Open Projects app. - Click on Studio button > Views > Try to activate Gantt view. -> `AccessError for read on stage_id` **Cause** The `stage_id` field used on the project gantt view is only readable if the project stages feature is enabled. https://github.com/odoo/enterprise/blob/b911ed1e857e1534c86495cd4934c1adb8ae9597/project_enterprise/views/project_views.xml#L12 **Solution** A hack is to add in the model metadata the `colorField` key used by the gantt renderer to color the pills: https://github.com/odoo/enterprise/blob/28f2fba988b1b225c97d15729020962ed4dee73b/web_gantt/static/src/gantt_renderer.js#L778 It is normally set when parsing the view here: https://github.com/odoo/enterprise/blob/dfe2795b820527a8226d8cf1afa5bf7ac8fcb53d/web_gantt/static/src/gantt_arch_parser.js#L194 This avoids trying to read the field if the user doesn't have the necessary `project.group_project_stages` group. Note: some missing views are also added in this commit, they were missing when the project stage feature wasn't enabled. opw-4592110