Thursday, May 7, 2026
13 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 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 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 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