Monday, January 19, 2026
12 changes · 18.0
Enhancements to existing features
This update ensures that Thai province names within Odoo are displayed in their native Thai language, improving accuracy and consistency. This change avoids translation issues and provides a more natural experience for users operating in Thailand.
Original PR description
State names are not translatable in Odoo, so they should be stored in their native language for consistency. This PR updates all Thai provinces to use their native Thai names. task-5484432 Forward-Port-Of: odoo/odoo#243461
This update expands Odoo's ability to handle Ukrainian Tax Identification Numbers (TINs). Previously, the system only accepted 12-digit numbers, preventing users from correctly entering 8-digit Ukrainian company and individual numbers. This change ensures accurate data entry for Ukrainian businesses and individuals.
Original PR description
with this commit:- - We are adding support for Ukrainian Tax ID numbers of 8 digits, which was 12 previously. - The following formats are now accepted: - National company numbers: 8 digits (e.g., 12345678) - European company numbers: 8 digits prefixed with 'UA' (e.g., UA12345678) - Individual numbers: 12 or 10 digits (e.g., 123456789012) - This change allows users to enter Ukrainian TINs that were previously incorrectly rejected due to length restrictions. task-5414806 opw-5373469
Resolved issues and error corrections
This update fixes a usability issue where the barcode on customer receipts was too narrow, making it difficult for staff to scan. The barcode width has been increased to ensure reliable scanning and accurate order processing. This improves the efficiency of our point-of-sale operations.
Original PR description
Step to reproduce; - install pos_loyalty - create a loyalty program of type "next order coupon" with minimum spend of 1$. - open pos and settle a order, see receipt. Issue: - currently bar-code is too narrow, making it difficult for to be scanned Fix: - increase the width of barcode, so it can be easily scanned. <table> <tr> <td> <b>Before</b> </td> <td> <b>After</b> </td> </tr> <tr> <td> <img width="451" height="508" alt="image" src="https://github.com/user-attachments/assets/a0d1e95e-0a9d-4552-977a-0ad9686867b8" /> </td> <td> <img width="456" height="517" alt="image" src="https://github.com/user-attachments/assets/40d04ac4-9ffc-4f81-a063-31b3ea26b4e1" /> </td> </tr> </table> opw-5363916 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242469
Code cleanup and technical improvements
This update enhances the testing process for Odoo's Arabic accounting modules (l10n_ar). Specifically, a new testing method has been implemented to better validate invoice data, and the entire test suite has been updated for consistency and accuracy. This ensures the Arabic accounting features continue to function correctly and reliably.
Original PR description
- Implemented a working `assert_json` method on `AccountTestInvoicingCommon`, that also supports the ignore_schema system and quick save using the `SAVE_JSON` test tag. - Refactors the whole test suite of `l10n_ar*` modules to use the new accounting test helpers properly. task-4891206
This update corrects a bug that occurred when attempting to change a tax lock date to a past date. The fix prevents the system from generating incorrect default values and triggering an error, ensuring accurate reporting. This improves the stability and reliability of financial reports.
Original PR description
To reproduce the issue, on a company in Luxembourg: 1) Set a tax lock date to November 30th 2) Attempt to change the tax lock date to November 15th ===> Lock date violation error. This happens because _generate_default_external_values still gets called in case the lock date is set back in the past (since _get_current_period_dates call in _create_default_report_external_values returns a tuple basically containing (former lock date + 1 day, new lock date)). Doing so, it tries generating a default external value with a value of 0 (because no data will ever be available in such an impossible date interval), but the previously set lock date prevents it, and raises the error. opw-5383010 Forward-Port-Of: odoo/enterprise#102756
This update corrects a bug that prevented users from importing XML invoices through the accounting module when the 'CustomizationID' tag was missing. The fix ensures that all UBL files now include this mandatory tag, allowing successful invoice processing. This resolves import errors and improves data accuracy.
Original PR description
[FIX] account_edi_ubl_cii: xml import error customization id This error happens when the user tries to import an xml invoice in accounting > customer > invoice and the CustomizationID tag is empty. The cause of this is the CustomizationID tag that exists in the file, but it's empty. This tag is mandatory in a ubl file, so we cannot process the file if it's empty. opw-5238398
This update resolves an issue where contacts created within a company branch couldn't be selected as customers in Field Service. Now, users operating from a branch company can seamlessly choose these contacts, mirroring their availability in Sales Order. This improves Field Service functionality and streamlines customer management within branch operations.
Original PR description
Steps to Reproduce: 1. Create a branch under an existing company. 2. Create a contact in company (so the contact is visible only to the company). 3. Switch to the branch of the company. 4. Open Field Service and create a new record. 5. In the *Customer* field, try to select the contact created earlier. Issue: The contact created under the company is not selectable in the *Customer* field in Field Service. Current behaviour: The same contact is visible in the Contacts app, and also selectable in Sales Order — but not in the Field Service. Expected behaviour: The contact created under the company should be selectable as a customer in Field Service when the current user is operating from that branch. Fix: Added domain on the field partner_id from xml in field services task's views. Task-5114444
This update resolves a problem where GS1 barcodes were causing errors during scanning, preventing products from being correctly identified. The fix allows the system to gracefully handle GS1 barcodes that don't conform to date formatting rules, ensuring accurate product and location detection.
Original PR description
Steps to reproduce: - Activate the GS1 nomenclature - Create a product with barcode: 15099590483921 - Scan the product from the Barcode app main menu Problem: A ValidationError is raised: "A GS1…
Steps to reproduce: - Activate the GS1 nomenclature - Create a product with barcode: 15099590483921 - Scan the product from the Barcode app main menu Problem: A ValidationError is raised: "A GS1 barcode nomenclature pattern was matched. However, the barcode failed to be converted to a valid date." Explanation: GS1 barcodes must follow a strict nomenclature based on well-defined rules. For example, a GS1 product barcode should start with the Application Identifier 01 followed by 14 digits. The GS1 parser processes the barcode rule by rule and applies the first matching rule. In this case, the barcode 15099590483921 is interpreted as a date because it starts with "15", which corresponds to a GS1 Application Identifier for a date. As a result, the parser attempts to convert the first six digits into a date and raises a ValidationError. Solution: Catch the ValidationError raised during GS1 date parsing in main_menu and explicitly reset parsed_results to False, allowing the normal main menu resolution logic to continue. This prevents GS1 parsing errors from blocking valid barcodes and ensures that product, picking, or location detection still works as expected. opw-5357611
This update resolves an issue where embedded buttons in the control panel were getting cropped due to incorrect height calculations during dragging. The fix ensures buttons accurately display their size, improving the user experience and preventing visual distortion. This change improves the overall appearance and functionality of the control panel.
Original PR description
The `o_embedded_actions` buttons are getting cropped when they are long enough. This is due to the `overflow-hidden` property which is now applied when no element are actively dragged. When an element is dragged after a css transformation, eg. the `o_dragged_embedded_action`, `getBoundingClientRect()` is returning the element height with the transformation. This creates an excess height on the `o_embedded_actions` due to the placeholder button having it's transformed height instead of the button height. Using offsetHeight returns the element size without the transform. Note this is not done on the width, because the width without the transform can lead to text-truncation. task-5225696 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a technical issue within the l10n_ro_saft module that was causing errors when generating SAFT reports. The fix ensures accurate reporting by correctly handling unit of measure data, preventing a 'singleton error' that impacted report generation. This improves the reliability of the SAFT reporting process.
Original PR description
`saft_template` in `l10n_ro_saft` adds a table that loops over the different Unit of Measures (`uoms`) available. The issue is that if the `uoms` are part of different categories (ie: Length and Weight) we get a singleton error as we're trying to access a non-relational field of a recordset with multiple records. The commit fixes the error by using the already defined variable `uom` OPW-5499918 Forward-Port-Of: odoo/enterprise#104478
This update resolves an issue where the l10n_mx_edi module was encountering a 'singleton error' when generating invoices with similar payment information. The fix ensures that the system correctly handles multiple invoices sharing the same payment details, preventing errors and improving invoice generation reliability. This ensures consistent invoice creation for users.
Original PR description
- for more then one records having same code it's raising an singleton error at fetching the name - error: ```py File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in…
- for more then one records having same code it's raising an singleton error at fetching the name
- error:
```py
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in _render_iterall
for item in frame.iterator:
File "<6403>", line 6097, in template_l10n_mx_edi_report_invoice_document_6403
File "<6403>", line 6083, in template_l10n_mx_edi_report_invoice_document_6403_content
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 616, in __str__
self.html = ''.join(self.irQweb._render_iterall(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in _render_iterall
for item in frame.iterator:
File "<6403>", line 1723, in template_l10n_mx_edi_report_invoice_document_6403_t_call_0
File "/home/odoo/src/enterprise/l10n_mx_edi/models/account_move.py", line 424, in _l10n_mx_edi_get_extra_invoice_report_values
cfdi_infos['payment_way'] = f'{payment_way} - {payment_method.name}'
^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/orm/fields.py", line 1659, in __get__
record.ensure_one()
File "/home/odoo/src/odoo/odoo/orm/models.py", line 5934, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: l10n_mx_edi.payment.method(23, 24)
```
- OPW-5450360
Forward-Port-Of: odoo/enterprise#103460This update streamlines the testing process for the l10n_ar_edi module by automatically verifying data against JSON files. This change allows tests to run without external modes and simplifies updates to test data through a simple tag, improving reliability and maintainability.
Original PR description
This commit refactors the whole `l10n_ar_edi` test suite to use the new helpers, and made it possible for the test to (finally) be run without external mode. Now, when running these new tests, the test framework will by default assert the request data with their associated JSON file. When a change is made, new overwrites for the test files can be easily changed by just adding the `SAVE_JSON` test tag on the command to run the tests. task-4891206