Daily updates from Odoo
Thursday, May 7, 2026
20 changes · saas-18.3
Resolved issues and error corrections
This update fixes a limitation in how Odoo Enterprise updates its UNSPSC product codes. Previously, new codes could only be added during initial installation, not subsequent updates. Now, an automated upgrade script runs on module updates, ensuring the database always reflects the latest UNSPSC codes. Existing product codes remain unchanged.
Original PR description
**Problem:** Periodically, the UNSPSC codes may be updated and they must be added to existing databases. Normally this is done by module update, however, since there are thousands of UNSPSC codes, a CSV imported via SQL is used instead of XML files. This import is only implemented on module install and not module update, so there is no way to update the UNSPSC codes in existing databases. **Solution:** An upgrade script based on the post-init hook has been added, which will add the new codes to the database, if any. Note that: - The version of this upgrade script should be bumped any time the codes list is updated. - Existing records will not be updated opw-5943366 Forward-Port-Of: odoo/enterprise#112652
This update resolves an issue where commission plans with negative target values caused a system error. The fix ensures the commission plan generation process can handle negative targets correctly, preventing errors and allowing for more flexible commission plan configurations. This improves the reliability of sales commission calculations.
Original PR description
Steps to reproduce: ------------------- 1. Install sale_commission 2. Create a commission plan based on targets 3. Try to add a new commission level with negative targets Issue: ------ Adding a commission level with a negative target results in a ```python RangeError: Maximum call stack size exceeded. ``` Cause: ------ https://github.com/odoo/enterprise/blob/2bfe0f32c0cec426fc7345ef716395146cc569ca/sale_commission/static/src/js/commission_plan_graph/commission_plan_graph.js#L50-L56 Negative target values caused infinite recursion in the GCD function, leading to this `RangeError`. Solution: ----------- Since the Euclidean algorithm only works correctly with non-negative integers, apply Math.abs() on both inputs before the recursion starts. This ensures negative targets are handled gracefully without causing infinite recursion. **NOTE:** Backport: c0d748f opw-6182644 Forward-Port-Of: odoo/enterprise#116050
This update corrects a bug in the Mod 349 tax report for Spanish businesses. Previously, amounts under 1 Euro were not displayed correctly. The fix ensures that all financial lines, regardless of their value, are accurately included in the report, improving data accuracy for tax reporting.
Original PR description
Steps to reproduce: - Install l10n_es_reports. - Create a company from France. - Create and post a vendor bill for that company with an amount of 0.12 EUR. - Open the Tax Return report and switch to the Mod 349 report for the current year. - Click the 0.12 EUR amount line. Observed: - The journal items view opens with no records. Cause: - `_get_modelo349_audit_aml_domain()` calls `_custom_modelo349_common()`, which filters lines using: `float_compare(result_dict['value'], 0, precision_rounding=2)` - Using `precision_rounding=2` treats values below 1 as equal to 0, so those lines are excluded from the audit domain. Fix: - Replace `precision_rounding` with `precision_digits=2` so values are only treated as zero when they are effectively below 0.01. opw-6134339 Forward-Port-Of: odoo/enterprise#116102 Forward-Port-Of: odoo/enterprise#114776
This update resolves a bug that prevented users from merging mailing lists, resulting in an error message. The fix ensures that the system correctly identifies and accesses mailing list IDs during the merge process, improving the reliability of this key feature. This change avoids a frustrating user experience.
Original PR description
Currently, error occurs when user tries to merge a mailing list. Steps to replicate: - Install `mass_mailing`. - Open Email Marketing > Mailing Lists > Mailing Lists and switch to list view. - Select…
Currently, error occurs when user tries to merge a mailing list.
Steps to replicate:
- Install `mass_mailing`.
- Open Email Marketing > Mailing Lists > Mailing Lists and switch to list view.
- Select a single record, and from cog menu Click merge.
Warning:
```
odoo.http: Record does not exist or has been deleted.
(Record: mailing.list(6,), User: 2)
```
Cause:
- When the user clicks Merge, the `mailing.list.merge` form opens and `default_get()` is executed to populate defaults.
- At this point, `src_list_ids` is added to res in a structured format like `[(6, 0, ids)]` [1].
- Later, `res.get('src_list_ids')` is reused and assigned to `src_list_ids` [2].
- Taking `src_list_ids[0]` [3] returns `(6, 0, ids)`, and its first element `6` is incorrectly treated as a record ID and assigned to `dest_list_id`.
- This leads to an attempt to access a record with ID 6, which does not exist, causing the error.
Solution:
- Instead of reading `src_list_ids` back from `res` after it has been set, we initialize and reuse local variables (src_list_ids, active_ids) at the beginning of the method.
- This avoids relying on transformed values in `res` and ensures that `dest_list_id` is computed using a consistent and valid list record IDs.
[1]: https://github.com/odoo/odoo/blob/21877c09863222a237fe99334787ac46935dcca4/addons/mass_mailing/wizard/mailing_list_merge.py#L20-L22
[2]: https://github.com/odoo/odoo/blob/21877c09863222a237fe99334787ac46935dcca4/addons/mass_mailing/wizard/mailing_list_merge.py#L24
[3]: https://github.com/odoo/odoo/blob/21877c09863222a237fe99334787ac46935dcca4/addons/mass_mailing/wizard/mailing_list_merge.py#L26
sentry-7447326420
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#262466This update corrects a display issue where archived opportunity activities were incorrectly shown in activity-related fields within contact lists. The fix ensures that 'Next Activity' fields always reflect the most current, active activities, providing a more reliable view of opportunity progress. This improves data accuracy for sales and customer management.
Original PR description
Steps to reproduce 1. Install crm, contact 1. Contacts → open a contact with an opportunity, if not present, create it. 2. From the Opportunities list view, add Studio fields “Next Activity Summary”…
Steps to reproduce 1. Install crm, contact 1. Contacts → open a contact with an opportunity, if not present, create it. 2. From the Opportunities list view, add Studio fields “Next Activity Summary” and “Next Activity Type”. 3. In the opportunity, create an activity and see the list view of opportunity now from Contacts → opportunity. 4. Mark the current activity as done and create a new activity. 5. Observe the list view again: it still shows the old activity summary/type. Issue - When opening Opportunities from a Contact, archived (done) activities are included in activity-related fields, so “Next Activity” fields can point to old activities. Root cause - Done activity records are now set to archived. The Contact → Opportunities action sets `active_test=False`. https://github.com/odoo/odoo/blob/9b071683e0eb270811302a4dd0ad10e0baaa0834/addons/crm/models/res_partner.py#L57 Since `activity_ids` had no domain, it included inactive activities, and related fields (`activity_summary`, `activity_type_id`) resolve to archived records. https://github.com/odoo/odoo/blob/9b071683e0eb270811302a4dd0ad10e0baaa0834/addons/mail/models/mail_activity_mixin.py#L49 Solution - Instead of passing active_test in context we will pass the domain to prevent the context interfear with activity fields. opw-5942696
This update fixes a minor calculation error related to Quebec Sales Tax (QST) reversal within the Swiss payroll module. The change ensures accurate tax reporting, aligning with Swiss tax regulations and improving the reliability of payroll data. This update was prompted by a previous issue and doesn't impact overall business operations.
Original PR description
opw 6133391 Fix for the source tax correction following PR #114463 Forward-Port-Of: odoo/enterprise#115585
This update corrects a minor typo in the automated tests for our Point of Sale (POS) module. The change ensures that test results are accurate and reliable, preventing potential issues with order processing. This is a routine fix to maintain the stability of the POS system.
Original PR description
Correct a typo in `test_01_order_flow` assertions. `pdis_order1` was reassigned multiple times; the second assertion should use `pdis_order2`. Task-6065459 Forward-Port-Of: odoo/enterprise#111917
A technical glitch in the website's drag-and-drop tour was causing it to fail. This fix ensures the tour functions correctly by waiting for snippets to fully load before proceeding, preventing errors related to unresponsive editors. This improves the user experience for website visitors.
Original PR description
`test_03_snippets_all_drag_and_drop` was consistently failing on runbot. The tour stopped after removing the snippet `s_dynamic_snippet_products` because no drop zones were found for the next…
`test_03_snippets_all_drag_and_drop` was consistently failing on runbot. The tour stopped after removing the snippet `s_dynamic_snippet_products` because no drop zones were found for the next snippet. **Cause** The public widget `DynamicSnippetProducts` performs an RPC call in `willStart` (~1 second), but it is still possible to delete the snippet while the promise is pending. In this case, the editor is unresponsive until the promise resolves. The tour fails because the snippet is removed while the promise is still pending, the editor is not ready to process the click on the next snippet, and no drop zones are generated. **How to reproduce the problem** This is impossible to trigger manually, but consistently happening on runbot. The easiest way to reproduce the problem is to add a delay in `_fetchData()`. **Fix** Wait for the snippet to finish loading before proceeding with the tour, ensuring the editor is responsive when the next steps runs. runbot-226770 Forward-Port-Of: odoo/odoo#262498
This update resolves an issue where paid orders using loyalty cards with archived programs would cause errors when opening the partner list. The fix ensures the system handles these scenarios gracefully, preventing disruptions to the sales process. This improves the reliability of our point-of-sale system.
Original PR description
Backport of https://github.com/odoo/odoo/commit/ffe46084665bb8a64ef9cd9f44b85f7178adf6f7 Before this commit, when loading a paid order with a loyalty card that its program had been archived, an error was raised when opening the partner list due to the missing program. opw-6182368 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262575
This update fixes a technical issue where a unit test was leaving temporary data in the database. Switching to a simpler `HttpCase` approach resolved this problem and paves the way for adding another test to address a related bug. This ensures the stability and reliability of our LDAP authentication process.
Original PR description
The unit test is tagged `-standard` and `database_breaking` because it was leaving left overs in the database. Using an `HttpCase` over a `BaseCase` solves that issue in addition to make the code way simpler. We want to resurrect this unit test class because we plan to add another unit test in that class for a bug fix. Forward-Port-Of: odoo/odoo#261842 Forward-Port-Of: odoo/odoo#261743
This update ensures a consistent look and feel for product and combo product cards across the point-of-sale system. Previously, combo items had a different background style, now they match the standard product cards, creating a more polished and user-friendly experience for customers.
Original PR description
In this commit: --- - Applied the same background styling to combo items as normal product cards. - Ensured visual consistency between product cards on the product screen and in combo configuration popup. | Before | After | | -------- | -------- | | <img width="979" height="447" alt="image" src="https://github.com/user-attachments/assets/6d91e1d7-99d5-47c4-a1bf-6604765d08d5" /> | <img width="979" height="453" alt="image" src="https://github.com/user-attachments/assets/602c9a8f-9e56-4633-84bf-0710cb5debab" /> | task-6103260
This update fixes an issue where users were redirected to the standard form view when opening documents linked through a Many2One field. Now, users can directly access the Kanban or List view, allowing them to preview and navigate documents, especially folders, more effectively. This enhances usability for document management.
Original PR description
Problem: When opening a linked `documents.document` record from a Many2One field added via Studio, the user is redirected to the standard form view. This is problematic because the form view does not allow the user to preview the actual document or navigate into it if the record is a folder. Solution: override `get_formview_action` to open the Kanban/List/Activity views. task-6068437 Forward-Port-Of: odoo/enterprise#116275 Forward-Port-Of: odoo/enterprise#113149
This update fixes an issue where public holidays without a working schedule weren't appearing in payroll reports. The fix modifies the system's search criteria to include all public holidays, regardless of whether they have a defined working schedule. This ensures accurate reporting for all holiday types.
Original PR description
### Steps to reproduce: - Create a public holiday without working schedule - Generate a SD worx for the month of the public holiday - Notice the public holiday is not shown in the report ### Cause: When searching for the public holiday we don't take into condsideration the holidays without working schedule. ### Fix: Modify the domain to fetch those holidays as well opw-5500070 Forward-Port-Of: odoo/enterprise#114900
This update fixes an issue where products with public categories weren't appearing on the website. The change reverts a previous update that was causing this problem, allowing products in public categories to be visible to customers. This ensures all products are accurately displayed, improving the customer experience.
Original PR description
This commit reverts 9ce0bf477b4490e654dcdd7e73c7813f1f68248c which is breaking stable. To reproduce: 1- Create a product with public category set and website published. 2- Assign a company to the product. The product under category is not shown in the website. opw-6197535 Forward-Port-Of: odoo/odoo#263248
This update resolves an issue where users could incorrectly manage bank accounts across multiple companies within the accounting system. The fix ensures that validation checks accurately reflect the current company configuration, preventing errors when attempting to delete accounts linked to multiple entities. This improves data integrity and reduces potential user confusion.
Original PR description
Steps to reproduce: - Install `l10n_dk` module - Create the test branches under the `DK Company` - Add both companies(parent and branch) in `Bank and Cash` account - Go to Chart of Accounts and try…
Steps to reproduce:
- Install `l10n_dk` module
- Create the test branches under the `DK Company`
- Add both companies(parent and branch) in `Bank and Cash` account
- Go to Chart of Accounts and try to delete any account
Cause:
This error occurs because users can add multiple companies to a `Bank and Cash` account, although it should be prevented by the `_check_company_consistency` [constrain]. However, the code still allows it because, in this [commit], `depends_context=('uid',)` was set on the `company_ids` field to keep separate sudo/non-sudo caches for the field. As a result, during the validation [check], the user may still have stale cached values, causing the system to detect only a single company.
Solution:
Here, we first clear all cached values for the old record and force the ORM to re-fetch the values from the database, ensuring an updated recordset. So, the validation error is raised when saving multiple companies.
[constrain]: https://github.com/odoo/odoo/blob/177fc59b7df7c8522234aaa4dbaeb4fba3bb2131/addons/account/models/account_account.py#L309-L310
[check]: https://github.com/odoo/odoo/blob/177fc59b7df7c8522234aaa4dbaeb4fba3bb2131/addons/account/models/account_account.py#L309-L310
[commit]: https://github.com/odoo/odoo/pull/220294/changes/5096d083a38968425920aa5bf466b156eebb3dc7
Ticket [link](https://www.odoo.com/odoo/project.task/6125840)
opw-6125840
Forward-Port-Of: odoo/odoo#260261This update corrects a bug where company-owned products weren't visible in the ecommerce shop. The issue stemmed from inconsistent website domain retrieval, leading to incorrect filtering of products based on company ID. By standardizing the website domain, this fix ensures all products, regardless of their ownership, are correctly displayed.
Original PR description
## Description ### Problem [sale_product_domain](file:///home/imanie/Documents/IRC/18.0/odoo/addons/website_sale/models/website.py#367-376) uses `self.get_current_website()` for the website domain…
## Description
### Problem
[sale_product_domain](file:///home/imanie/Documents/IRC/18.0/odoo/addons/website_sale/models/website.py#367-376) uses `self.get_current_website()` for the website domain
but `self.company_id` for the company domain. This causes two issues:
1. **`company_id` is `False` when called from [models](https://github.com/odoo/odoo/blob/b011c1e3cc4597c713dfe7041c58dc224f8f758d/addons/website_sale/models/product_template.py#L278)**: Methods like
[_get_website_accessory_product](file:///home/imanie/Documents/IRC/18.0/odoo/addons/website_sale/models/product_template.py#198-203) and [_get_website_alternative_product](file:///home/imanie/Documents/IRC/18.0/odoo/addons/website_sale/models/product_template.py#204-207) call
`self.env['website'].sale_product_domain()` — an empty recordset where
`self.company_id.id` evaluates to `False`. The resulting company domain
[('company_id', 'in', [False, False])](file:///home/imanie/Documents/IRC/18.0/odoo/addons/website_sale/controllers/main.py#757-802) filters out all company-owned
products.
https://github.com/odoo/odoo/blob/b011c1e3cc4597c713dfe7041c58dc224f8f758d/addons/website_sale/models/product_template.py#L279
2. **Inconsistent website references**: Even when `self` is a real website
record, `get_current_website()` could return a different website, leading to
the website domain and company domain referring to different websites.
### Steps to reproduce
1. Add accessory products to a product template
2. Visit the product page on the ecommerce shop
3. Accessory products belonging to the website's company may not appear
### Solution
Store the resolved website in a local variable (`self or self.get_current_website()`),
preferring `self` when it is a real record and falling back to
`get_current_website()` otherwise. Use this single variable for both the website
domain and the company domain.
```diff
def sale_product_domain(self):
- website_domain = self.get_current_website().website_domain()
+ website = self or self.get_current_website()
+ website_domain = website.website_domain()
if not self.env.user._is_internal():
website_domain = expression.AND([website_domain, [
('is_published', '=', True),
('service_tracking', 'in', self.env['product.template']._get_saleable_tracking_types()),
]])
- company_domain = [('company_id', 'in', [False, self.company_id.id])]
+ company_domain = [('company_id', 'in', [False, website.company_id.id])]
return expression.AND([self._product_domain(), website_domain, company_domain])
```
https://github.com/odoo/odoo/pull/260138
Forward-Port-Of: odoo/odoo#263185This pull request updates the core spreadsheet component, addressing several bugs and improving stability. It fixes issues related to chart visibility, error messages, and button functionality within the spreadsheet interface. The update also includes code improvements for consistency and dependency management.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/d88c24e795 [FIX] chart: ensure chart values remain visible (remove clipping) [Task:…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/d88c24e795 [FIX] chart: ensure chart values remain visible (remove clipping) [Task: 5993132](https://www.odoo.com/odoo/2328/tasks/5993132) https://github.com/odoo/o-spreadsheet/commit/d854983ab3 [FIX] Gauge chart: error message in the side panel [Task: 6179300](https://www.odoo.com/odoo/2328/tasks/6179300) https://github.com/odoo/o-spreadsheet/commit/49d0b4dffa [FIX] grid overlay: unhide buttons visibility [Task: 6127335](https://www.odoo.com/odoo/2328/tasks/6127335) https://github.com/odoo/o-spreadsheet/commit/dd00c1135e [REF] lint: enforce braces for all control statements [Task: 6140827](https://www.odoo.com/odoo/2328/tasks/6140827) https://github.com/odoo/o-spreadsheet/commit/e2e096d9cb [FIX] package: add missing types dependency [Task: 6140820](https://www.odoo.com/odoo/2328/tasks/6140820) https://github.com/odoo/o-spreadsheet/commit/b24082bd32 [FIX] pivot: `getPivotCellFromPosition` will throw on invalid formula [Task: 6109696](https://www.odoo.com/odoo/2328/tasks/6109696) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update ensures that if a Stripe terminal payment capture fails, the payment status in Odoo POS is correctly set to 'retry' instead of being marked as 'done' silently. This prevents inaccurate payment records and ensures that payment issues are visible and addressed within the POS system.
Original PR description
Before this commit, a Stripe terminal payment could still be marked as `done` even if the capture step failed. This happens when the card authorization succeeds, `processPayment` returns a payment…
Before this commit, a Stripe terminal payment could still be marked as `done` even if the capture step failed.
This happens when the card authorization succeeds, `processPayment` returns a payment intent, but the subsequent `stripe_capture_payment` RPC fails and `capturePaymentStripe()` returns `false`. The capture flow did not guard that return value and still fell through to `line.set_payment_status("done")`.
In practice, this can happen for example if the Odoo server cannot resolve `api.stripe.com` while capturing the payment intent. Stripe then keeps the payment in `requires_capture`, while the POS line is still synced as paid.
Guard the failed capture path and stop the flow before marking the line as done. In that case, the payment line is put back to `retry` so the failure is visible in the POS instead of silently creating a paid, uncaptured payment.
opw-6075384
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#261521This update removes a redundant process in our account EDI system that was previously used to handle different data formats for electronic invoices from Belgium (BE). Previously, the system was switching between two formats, but now we exclusively use the standard 0208 format. This simplifies the system and improves efficiency.
Original PR description
When adding peppol, we didn't know if we needed to use the 9925:BE or 0208. Therefore, we switched between them if the endpoint was not found. This has no more use today as we use 0208. opw-5976574 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261307 Forward-Port-Of: odoo/odoo#258297
This update resolves an issue where payment reminders wouldn't display correctly when the 'Payment' module wasn't installed. The fix ensures the system checks for the necessary 'payment.method' model before attempting to use it, preventing a template rendering error.
Original PR description
Repro steps: 1. Initialize a new DB 2. Install account_followup module without payment module 3. Go to Email templates > Payment reminder 4. Click on Preview You will get an error Failed to render QWeb template for Mail Template: 'Payment Reminder' (ID: 9) Target Model: res.partner Language context: en_US Error: Error while render the template KeyError: 'payment.method' Root cause: The method `_show_pay_now_button` that was being called in the template email_template_followup_1 was using self.env['payment.method'] even tho payment module is not a dependency of account_followup Fix: The introduced fix ensures that 'payment.method' model exists before attempting to use it build_error-243030 Forward-Port-Of: odoo/enterprise#116443 Forward-Port-Of: odoo/enterprise#116079