Tuesday, January 20, 2026
22 changes · saas-18.4
Enhancements to existing features
This update expands Odoo's ability to handle Ukrainian Tax Identification Numbers (TINs). Previously, only 12-digit numbers were accepted. Now, 8-digit numbers (and 10 or 12-digit variations) are supported, resolving an issue where Ukrainian users were unable to correctly input their TINs.
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 Forward-Port-Of: odoo/odoo#243258
This update streamlines the accounting process for Ecuadorian businesses within Odoo. It simplifies expense categorization by consolidating accounts and adding a new account for specific benefits, while also preventing unnecessary reconciliation for income statement accounts. This improves accuracy and efficiency.
Original PR description
Improve the distribution of expense and cost of revenue accounts in Ecuadorian localization We avoided not creating subcategories of expenses by eliminating the group called "Other employee benefit plan expense", which generated duplicity in the accounts. We fixed this by merging the accounts into the main "Employee benefit plan expense" group. Additionally, the account "Other employee benefits' was added to record any other benefits granted directly by the Ecuadorian companies. This ensures a better organization of the accounting setup. Mark as non-reconcilable the expense accounts (salaries and wages, travel expenses, contributions, etc) to avoid unnecessary reconciliation processes, these accounts are income statements and they are not accounts payable/receivable, therefore, they are closed at the end of the accounting period ### opw-4846355 Forward-Port-Of: odoo/odoo#208047
Resolved issues and error corrections
This update resolves an issue that occurred when users attempted to 'Show', 'Force CFDI', or 'Retry' operations on MX electronic invoices. The problem stemmed from a system error when payments were cancelled or deleted, leading to incorrect invoice data. This fix ensures a smoother process for generating and submitting CFDI invoices.
Original PR description
When user is clicking any of the `Show`, `Force CFDI`, or `Retry` buttons in l10n_mx_edi.document error occurs. Steps to reproduce: - Install `l10n_mx_edi` module > Switch to `MX Company` - Setup `MX Electronic invoicing` in settings - Create a New Invoice > Send > Select `CFDI` > `Pay` > `Update Payments` - Payment > Cancel that Payment > Back to Invoice > CFDI(Notebook page) > Click on `Show` or `Force CFDI` or `Retry` Traceback: `ValueError: Expected singleton: account.move()` This error occurs when a payment is created and later deleted or cancelled, which results in an empty `move_id` in l10n_mx_edi.document. sentry-7113267386 Forward-Port-Of: odoo/enterprise#102248
This update fixes a technical issue that caused errors during server shutdowns. Specifically, the server stop process was incorrectly closing database connections before the system was ready, leading to errors. This change ensures that these errors are now gracefully handled, improving server stability and reliability.
Original PR description
When the server stops, pool errors can occur. It's due to the server stop function calling `sql_db.py@close_all()`. If this occurs before the dispatcher loop wakes up, the `__exit__` function of the cursor context manager will raise an error, because the connection has already been popped from the pool. As for interface errors in [1], pool errors should be ignored during server shutodwn. runbot-229800 [1]: https://github.com/odoo/odoo/pull/99849 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#244481
This update corrects a minor issue related to testing within the live chat feature. Previously, outdated tests were causing problems. The PR removes these unnecessary tests, ensuring the canned response functionality works as intended and avoids potential conflicts.
Original PR description
In [1], auto focus was removed for canned responses in the navigable list. The intent was to avoid conflicts with emojis. In [2], the shortcut for canned response was changed to `::` and the auto focus behavior was restored. However, tests added in [1] were not removed. Since they were fragile (negative assertion), they are passing most of the time. This PR removes the tests that are now outdated. runbot-233358 [1]: https://github.com/odoo/odoo/pull/170900 [2]: https://github.com/odoo/odoo/pull/192953 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#244472
This update resolves an issue where tables inserted into the To-Do editor appeared after the existing text instead of before it. The fix streamlines the table insertion process, ensuring tables are placed correctly at the desired cursor position. This improves the user experience and prevents formatting inconsistencies.
Original PR description
### Steps to Reproduce : - Open To-Do and type some text. - Place the cursor at the start of the block. - Insert a table. (e.g.: /table) - The table appears after the text instead of before it. ### Purpose of this PR: - Table insertion logic was previously duplicated inside TablePlugin, where it tried to manually split text and inline nodes before inserting the table. However, this responsibility is now correctly handled by `DomPlugin.insert()`, which already: - deletes the current selection if needed. - splits text and inline nodes safely. - handles block boundaries and unsplittable elements. - normalizes the DOM after insertion. - places the cursor at a valid position. task-5480759 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244435 Forward-Port-Of: odoo/odoo#243242
This update fixes a minor usability issue in the contact record view. The GLN field was awkwardly positioned and lacked a label, making it difficult for users to find. The change repositions the field before the notes field for better clarity and discoverability.
Original PR description
The field is placed weirdly in the view when opening the contact view of the delivery address. There is no label, making it almost impossible to discover, and it is in the middle of everything. Let's put it down before the notes field. Before: <img width="971" height="510" alt="image" src="https://github.com/user-attachments/assets/2e0e7d96-1a7f-4fe5-b17d-4c5b25a3e7bf" /> After: <img width="824" height="554" alt="image" src="https://github.com/user-attachments/assets/3bc47f20-72a9-4247-8dd3-9e939046c6d7" /> task-none Forward-Port-Of: odoo/odoo#244554
This update resolves an issue that prevented users from exporting SAFT reports for Austrian companies without defined contacts. The fix eliminates a redundant check, ensuring the system correctly identifies companies needing contact information before attempting the export. This improves the reliability of the SAFT generation process for Austrian clients.
Original PR description
[FIX] l10n_at_saft: saft export traceback When no contacts is defined on the company and the user tries to download the SAFT to XML, a traceback is shown Steps to reproduce the traceback: - Install l10n_at_saft module and create an Austrian company with no contacts - Create a few invoices for this company - Open the General Ledger report and export SAFT to XML, the traceback should appear no-task Forward-Port-Of: odoo/enterprise#104633 Forward-Port-Of: odoo/enterprise#104144
This update fixes a gap in translation coverage for employee profiles within the Odoo Enterprise system. Specifically, fields related to payroll and language settings were missing translation in several localized modules. This ensures consistent and accurate user experiences for employees across different languages and regions.
Original PR description
Following the refactor of `hr.contract` to `hr.version`, some fields of the employee's version were not translated (e.g. install belgian payroll, switch to french and go to "Paie" tab of employee's profile). Fix: replace occurences of `field_hr_contract__` in `l10n_*` modules. opw-5062209
This update resolves an issue where the Amazon connector wasn't correctly identifying key delivery modules for major shipping carriers (UPS, FedEx, USPS, DHL). By mapping these modules, the connector now functions as intended, ensuring accurate shipping integration with Amazon. This improves the reliability of order fulfillment.
Original PR description
Amazon connector did not recognize the _rest delivery modules (ups_rest, fedex_rest, usps_rest, dhl_rest). This maps them to the correct carrier names, consistent with existing mappings. Forward-Port-Of: odoo/enterprise#102606
This update resolves an issue where embedded buttons in the Odoo Control Panel were getting cropped due to incorrect height calculations during dragging. The fix ensures that the buttons display their actual size, preventing visual distortion and improving the user experience. This change improves the overall usability 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 Forward-Port-Of: odoo/odoo#234120
This update enhances the security of user profile editing within the website. It replaces an older check with a new, more reliable method for determining if a user is authorized to change their country setting. This change ensures consistent and secure profile management across the SaaS platform.
Original PR description
In 'save_edited_profile()', we check that the user can edit his country_id if he tries. As from saas-18.4, a new helper '_can_edit_country()' is available. This commit uses that helper to perform the check. Follow-up of #239789 Task-5331916
This update resolves an issue where URLs were appearing twice in WhatsApp messages due to a formatting error in how the Odoo UI's HTML was converted to plain text. The fix prevents this duplication, ensuring users receive messages with URLs correctly formatted and avoiding potential confusion. This improves the clarity and usability of WhatsApp communication within Odoo.
Original PR description
Steps to reproduce: 1. Set up whatsapp integration. 2. Send a direct message containing a URL. 3. Observe that the URL appears twice in the message received in whatsapp. Issue: This issue arises…
Steps to reproduce: 1. Set up whatsapp integration. 2. Send a direct message containing a URL. 3. Observe that the URL appears twice in the message received in whatsapp. Issue: This issue arises within the `_send_message` method, where we are taking the Markup body that we use within the Odoo UI to have a clickable URL, like `<a href="https://example.com">https://example.com</a>`. Then, the html2plaintext function duplicates by adding the footnote for the anchor tag, which "duplicates" the URL since the text within the anchor tag is the same as the URL itself. This results in a message body that contains the URL twice, leading to confusion for the user. Solution: This commit addresses the issue by backporting the solution to this problem introduced in odoo/odoo@a152910 and using the `include_references` parameter of the `html2plaintext` function to exclude footnotes from the conversion. opw-4936400 Forward-Port-Of: odoo/enterprise#104252 Forward-Port-Of: odoo/enterprise#101083
This update fixes a potential issue where the website editor could fail to open correctly under certain network conditions. By delaying editor initialization until the iframe is fully loaded, the system now provides a more consistent and reliable editing experience. This ensures users can consistently create and manage website content.
Original PR description
Steps to reproduce: 1. Set network speed to 3G 2. Create website Page from the systry new menu 3. click on edit button You'll face the traceback. The website editor could try to open before the iframe finished loading, leading to non-deterministic behavior. This commit ensures the editor initializes only after the iframe load event, making the edit action consistent and reliable. Erlier fixed was not covering the all the cases. PR: https://github.com/odoo/odoo/pull/238054 runbot-233039
This update fixes a potential issue in the Nilvera accounting module where the default journal type was incorrectly set. The default has been changed from 'in_invoice' to 'purchase' to prevent incorrect document processing. This ensures documents are created with the appropriate accounting settings.
Original PR description
…hing The default value of the journal type parameter was incorrectly set to a move type (`in_invoice`). Although all current callers explicitly pass the correct journal type, the default value has been corrected to `purchase` to avoid potential misuse. no task-id Forward-Port-Of: odoo/odoo#242865
This update removes unnecessary integer rounding from monthly VAT reports for Italy. The rounding was mistakenly carried over from annual reports, impacting the accuracy of monthly financial data. This change ensures consistent and correct reporting of VAT obligations.
Original PR description
Integer rounding is only required on annual l10n_it VAT reports. It appears that it was incorrectly added to the monthly report when the two were split in [#193662](https://github.com/odoo/odoo/pull/193662). [opw-5292310](https://www.odoo.com/odoo/project.task/project.task/5292310) Forward-Port-Of: odoo/enterprise#104228 Forward-Port-Of: odoo/enterprise#103852
This update prevents a problem where users in different branches could create the same tax name. Previously, Odoo only checked for duplicates within a user's visible branches. Now, Odoo checks all branches to guarantee each tax name is unique, avoiding errors and ensuring data consistency across the entire organization.
Original PR description
**Description of the issue/feature this PR addresses:** In companies with many branches, a user could create a tax name that already exists in another branch. This happened because Odoo only checked for duplicates in the branches the user could see. To reproduce: 1. Create `Branch A` and `Branch B`. 2. A user with access ONLY to `Branch A` creates "Tax 1". 3. A user with access ONLY to `Branch B` creates "Tax 1". 4. Both are saved, creating a duplicate name. This fix adds sudo() to the check. Now, Odoo will check all branches to make sure the name is unique, even if the user cannot see the other branches. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243185
This update resolves an issue that prevented users from creating payslips for contracts without a defined working schedule in Belgian companies. The fix ensures that the system defaults to the company's standard calendar when a contract lacks a specific schedule, preventing a traceback error. This improves the reliability of payslip generation.
Original PR description
Currently, a traceback occurs when a user tries to create a payslip for a contract that has no working schedule in a Belgian company. **Steps to reproduce this issue:** 1) Install l10n_be_hr_payroll…
Currently, a traceback occurs when a user tries to create a payslip for a contract that has no working schedule in a Belgian company. **Steps to reproduce this issue:** 1) Install l10n_be_hr_payroll and hr_attendance and switch to BE company 2) Create an employee with no working hours. 3) Create a contract for that employee with: - Work entry source as Attendance - No Working Schedule - State should be open/running 4) Click the Payslip smart button to create a new payslip for that contract. 5) A traceback occurs **Error:** ``` ValueError: Expected singleton: resource.calendar() ``` **Cause:** When creating a payslip for a contract with no resource_calendar_id, the method `_get_work_hours_split_half` calls `_get_max_number_of_hours` through self.resource_calendar_id. Since the contract's calendar lacks a resource_calendar_id, this triggers a ValueError in `_get_max_number_of_hours`. https://github.com/odoo/enterprise/blob/193b51ded0dfa46ed75f6c0020f0f5609f4a0f99/l10n_be_hr_payroll/models/hr_contract.py#L472 **Solution:** If the contract or employee does not have a resource_calendar_id, use the default resource_calendar_id from the company instead. opw-5237559 Forward-Port-Of: odoo/enterprise#103059 Forward-Port-Of: odoo/enterprise#99217
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 handle GS1 barcodes without interruption, ensuring accurate product and location detection within the Odoo Enterprise system.
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 Forward-Port-Of: odoo/enterprise#104641
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
A recent update introduced a bug in the delivery module, causing incorrect calculations. This pull request reverts the problematic change to restore the original, correct behavior. The issue will be addressed in a future update.
Original PR description
Bug introdcued in: https://github.com/odoo/odoo/commit/6901863d30f524c160971c9f5c97846ffd1fa5f5 The fix was misleading because forcing the context in the unit test caused incorrect assumptions. Passing `default_carrier_id` in the context prevents the computed method from being called, breaking expected behavior. This revert restores the previous behavior as the fix is incorrect. The issue will be resolved in another PR.
This update fixes a potential issue where payroll calculations in the US could incorrectly show employees owing money to the state. The change ensures that taxable income defaults to zero when state deductions exceed gross income, preventing negative values on payslips and ensuring accurate tax reporting.
Original PR description
This commit simply defaults the computed taxable income amount to 0 in case the state deductions are greater than their gross income. Otherwise our payslips would imply that these employees are owed money by the state opw-5137280 Forward-Port-Of: odoo/enterprise#102599 Forward-Port-Of: odoo/enterprise#98114