Friday, January 16, 2026
13 changes · saas-18.4
Resolved issues and error corrections
This update resolves an issue where applying a zero-amount discount on sale orders would trigger an error. The fix ensures the system handles zero discounts gracefully, preventing disruptions to the sales process. The change improves data integrity and user experience.
Original PR description
The system raises an error when the user tries to apply a fixed amount discount of 0.0. **Steps to produce:** - Install `Sales` module with demo data. - From the settings enable `discount`. - Make a sale order with product > click on Discount > click Fixed Amount and set amount as `0.0` > click on apply. **Error:** `ZeroDivisionError : float division by zero` **Cause:** - When the discount amount is set to 0.0, at [1] we attempt to compute the factor, which causes an error due to a division by zero. **Solution:** - Added a condition to check that current_base_amount_currency is not zero, and if it is, set the factor to 0.0. [1]: https://github.com/odoo/odoo/blob/10887c3081afbfd0734c6a3ac24301c94d14bc24/addons/account/models/account_tax.py#L3718-L3720 **sentry-6967181350** I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233151
This update resolves an issue where users would encounter access errors when closing the 'Thank You' dialog after signing a document from a record they couldn't access. The fix ensures the system verifies read access to the related record before redirecting, resulting in a smoother sign-off experience for users.
Original PR description
Version: - 18.0 Steps to reproduce: - Send a signature request to an internal user from a record that the signer cannot access. - The user signs the document and then tries to close the Thank You dialog. Before: - When a user signs a document sent from a record they don’t have access to, closing the "Thank You" dialog triggers an access error. - This happens because the system tries to open the related record after signing, but the signer does not have permission to view that record. After: - Now the system first checks if the signer has read access to the related record before redirecting. Impact: - Users will not see an access error message after signing a document. task-5353126 Forward-Port-Of: odoo/enterprise#104161 Forward-Port-Of: odoo/enterprise#100961
A customer modified their Gift Card and E-Wallet products to use inventory, causing an inconsistency in the system. This fix prevents these products from being automatically converted back to service-type products, maintaining accurate inventory counts. This change addresses a recurring customer request and highlights the need for a more general solution.
Original PR description
The customer changed the service-type products “Gift Card” and “E-Wallet” to storable products and used them in stock. May be they could use as physical gift cards, and physical e-wallets for company. As a result, these products now have on-hand quantities, which creates an issue. After the upgrade, they will be converted back to service-type products, causing an on-hand quantity inconsistency in the test case. To avoid this error, we need to keep these products as storable. TO do that we have to mark them noupdate. This is a customer-specific change, but since we have received many similar requests, we should consider making a generic fix if possible. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242555 Forward-Port-Of: odoo/odoo#237517
This update removes a redundant CSS class from the Point of Sale module. The class was previously used to limit button width but is no longer needed in the current design. This cleanup improves the codebase and reduces potential styling conflicts.
Original PR description
The issue was to put the button css class at a max width of 200px. But it's not used anymore. So it can be deleted bug was created from this pr : https://github.com/odoo/odoo/pull/243770 task : 5493872 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243831
This update corrects a bug in how the system identifies sub-locations within the stock management system. Previously, matching location IDs could lead to incorrect sub-location detection. This fix ensures accurate sub-location identification, preventing potential errors in related processes.
Original PR description
Previously, in the `_isSublocation`, to check if a location was a children of another location, we did that: ```javascript return childLocation.parent_path.includes(parentLocation.parent_path); ```…
Previously, in the `_isSublocation`, to check if a location was a children of another location, we did that: ```javascript return childLocation.parent_path.includes(parentLocation.parent_path); ``` The issue with that is, if locations' id are aligned, they can match even if they are not related. For example, imagine tested child location has ID 127 and the parent location has ID 7, we then check their `parent_path` (for example, '4/127/' for the child location and '7/' for the parent location), it can happen the child parent path can include the parent's parent path (in our example, '4/127/' includes '7/'.) To fix that, this commit replaces `includes` with `indexOf`, the result of the `indexOf` should always be 0 if the child location is indeed a sublocation of the parent location. Because of this issue, the second run of the tour `test_put_in_pack_new_lines` could sometime fail when the locations IDs are aligned. runbot build error: [233292](https://runbot.odoo.com/odoo/runbot.build.error/233292) Forward-Port-Of: odoo/enterprise#104350
This update addresses a technical issue related to how Odoo handles record deletions, specifically cascade deletes in the database. It ensures that related records linked to messages and activities are not accessed after deletion, improving overall system performance and stability. This change was prompted by a community recommendation to enhance data management practices.
Original PR description
In order to be defensive we have to check records linked to messages, notifications or activities exist before checking related information like display_name, or even to skip them in various flows. This happens notably due to DB-level cascade deletion that does not remove side records linked through (model, res_id) pairs. It implies some additional exist queries. Task-5138556 Forward-Port-Of: odoo/enterprise#104410 Forward-Port-Of: odoo/enterprise#101185
This update resolves an issue preventing stable IoT Box responses from being correctly interpreted. The system now prioritizes data from a specific key, ensuring that IoT Box data is reliably displayed and processed. This enhances the overall stability and functionality of the IoT integration.
Original PR description
We now read data in result key if it exists to ensure readability of stable IoT Box responses. Forward-Port-Of: odoo/enterprise#104360 Forward-Port-Of: odoo/enterprise#104113
This update fixes a display issue where tax names and invoice labels were shown in English for Vietnamese users. By adding the necessary Vietnamese translations to the chart template CSV, users will now see these labels in Vietnamese, improving the user experience for Vietnamese-speaking businesses using Odoo.
Original PR description
The `name` and `invoice_label` fields on `account.tax` are translatable fields (translate=True), but the Vietnamese chart template CSV was missing the corresponding translation columns. This caused…
The `name` and `invoice_label` fields on `account.tax` are translatable fields (translate=True), but the Vietnamese chart template CSV was missing the corresponding translation columns. This caused tax names and invoice labels to display in English even when the user's language was set to Vietnamese. By adding the `name@vi_VN` and `invoice_label@vi_VN` columns to the tax template CSV, taxes will now display with proper Vietnamese labels when the chart of accounts is installed for Vietnamese companies, improving the user experience for Vietnamese-speaking users. Technical details: - Added `name@vi_VN` and `invoice_label@vi_VN` columns to the CSV header - Added Vietnamese translations for all tax records in the template - Translations follow Vietnamese tax terminology conventions - The chart template loader automatically processes columns with `@lang` suffix and applies them as translations for translatable fields Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242437 Forward-Port-Of: odoo/odoo#236502
This update fixes an issue where the link popover remained open after a snippet was removed from the website. The change ensures the popover closes automatically when a snippet is deleted, improving the user experience and preventing visual clutter. This resolves a minor usability problem.
Original PR description
Description of the issue this PR addresses:
- When removing a snippet, the link popover stayed open because its `pointerdown` handler didn’t trigger, leaving the popover visible even after its selected content element was removed.
- A previous fix used { capture: true } on the document `pointerdown` listener, but this also triggered when interacting with the link type `dropdown` and color picker, closing the popover triggers `applyCallback` and causing nested links to be created.
After this commit:
- Close the link popover from `on_will_remove_handlers` before the target element is removed from the DOM.
- This ensures the popover closes when removing the snippet.
task-5359000
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves an issue where the 'Other Input' section of the Payroll app incorrectly displayed trailing zeros for negative salary attachment counts. The fix adjusts a widget to properly handle negative values, ensuring accurate reporting of attachment numbers. This improves the clarity and reliability of payroll data.
Original PR description
Steps to Reproduce: - install Payroll app - create an employee and create a salary attachment. - check the negative value for salary attachment - generate a payslip Issue: - In "Other Input" section, salary attachment count displays value with trailing decimal zeros for negative amounts. Reason: - The field is using the widget float_without_trailing_zeros which should remove the extra decimal zeros but it doesn't work when the value is negative. Solution: - Fix the regular expression in the float_without_trailing_zeros widget to handle negative values and properly remove trailing decimal zeros. task-5477466
This update corrects a data inconsistency in Odoo, ensuring Bulgaria's currency is accurately listed as EUR. As Bulgaria transitions to using the Euro on January 1, 2026, this change aligns Odoo's data with the latest official currency information. This ensures accurate reporting and financial processes related to Bulgaria.
Original PR description
Description of the issue/feature this PR addresses: Bulgaria adopted the euro as official currency as of 2026-01-01. Update the base country data accordingly. Current behavior before PR: In `res_country_data.xml`, Bulgaria is linked to BGN. Desired behavior after PR is merged: Bulgaria is linked to EUR in `res_country_data.xml`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241957
This update resolves a technical issue causing tracebacks when generating the Follow-up Report in Partner Ledger. It ensures that general accounting entries are automatically set to 'no_followup', streamlining reporting. Importantly, payments from Point of Sale (POS) systems are still included in follow-up reports.
Original PR description
* Fix traceback when opening the follow-up report and customer statement. * General(MISC) entries should be no_followup by default. Except entries coming from pos should not be excluded from follow-ups. Forward-Port-Of: odoo/enterprise#104500 Forward-Port-Of: odoo/enterprise#104433
This update resolves an issue where rapid receipt printing via USB printers occasionally caused errors. The fix ensures only one thread can access the printer at a time, preventing conflicts and guaranteeing reliable printing performance. This improves the overall stability of the receipt printing process.
Original PR description
When printing many receipts quickly using a USB printer, this error was occasinally occuring: ``` WARNING ? odoo.addons.iot_drivers.iot_handlers.drivers.printer_driver_base: Failed to query ESC/POS…
When printing many receipts quickly using a USB printer, this error was occasinally occuring: ``` WARNING ? odoo.addons.iot_drivers.iot_handlers.drivers.printer_driver_base: Failed to query ESC/POS status ERROR ? root: Could not set configuration: [Errno 16] Resource busy ``` This would cause `python-escpos` to be disabled and fallback to just CUPS printing. The issue was caused by two threads trying to access the printer at the same time, which could happen in two ways: - IoT thread with `python-escpos` and CUPS try to access the printer at the same time. - Two IoT threads with `python-escpos` try to access the printer at the same time (this can happen if two receipt actions are received at the same time). Both of these scenarios should now prevented: - Now, if we are using `python-escpos`, we also use it to print the receipt as well as checking the status. CUPS is never used so there should be no interference from it. - We now have an `escpos_lock` (per printer, not global) that is acquired when accessing the printer via `python-escpos`. This ensures that different threads cannot both try to access the printer at the same time. task-5490942 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr