Thursday, February 12, 2026
15 changes · saas-18.4
Resolved issues and error corrections
The Saudi e-invoicing setup no longer fails when a company's street address is left blank. This helps users complete ZATCA journal onboarding with an OTP even when optional address details are missing.
Original PR description
This error occurs when attempting to set the "OTP" received from "ZATCA". Steps to reproduce: - Install `l10n_sa_edi` module > Switch to `SA Company` - Go to `SA Company` and remove `Street` - Journals > Open journal with type 'Sale' > ZATCA > Onboard Journal > Enter any OTP > Request Traceback: `TypeError- value argument must be a str` At [1], the error occurs because the company has an empty street field, causing the value argument to be a `boolean` instead of the expected `string`. [1]- https://github.com/odoo/odoo/blob/40a0b44231fd9a725ccf3667c4992e691e24cde7/addons/l10n_sa_edi/models/certificate.py#L71 sentry-7185302332 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243525
The Discuss app now includes an updated call-routing component used for online meetings. This maintenance update helps keep voice and video discussions aligned with the latest upstream fixes, improving reliability without changing how users work.
Original PR description
https://github.com/odoo/sfu/releases/tag/v1.3.3 Forward-Port-Of: odoo/odoo#246979 Forward-Port-Of: odoo/odoo#244971
Cancelling a combo product selection in Point of Sale no longer adds an empty, zero-priced line to the order. This keeps receipts and orders cleaner and avoids confusion for cashiers and customers.
Original PR description
When discarding a combo product in the POS, it was creating an empty orderline with the product with a price of 0.0$. How to reproduce ? 1. Open a POS 2. Click on a combo product 3. Press ESC or press the cross icon 4. It creates an order line with the parent combo with a quantity of 0 and a price of 0.0 Fix : It’s because the popup payload returns undefined when the user discards it, but the condition was checking for false instead of undefined. task: 5868094 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246681
This change makes an automated test for image uploads wait for the image data conversion to complete instead of relying on timing assumptions. It reduces random test failures, helping keep release validation more stable without changing user-facing behavior.
Original PR description
Encoding the data to base64 can take some times. Before this commit we used this code: ```js await runAllTimers(); await animationFrame(); ``` Now we explicitly wait for the change to happen as awaiting an animation frame can't be enough. runbot-error-237568 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248166
This update makes an automated Point of Sale tax test wait for the invoice option to finish updating before validating an order. It helps prevent false test failures in localization scenarios, improving release stability without changing user-facing behavior.
Original PR description
The `test_point_of_sale_custom_tax_with_extra_product_field` test does a `PaymentScreen.clickInvoiceButton()` and then directly after that a `PaymentScreen.clickValidate()`. In l10n scenarios, the logic behind triggering the `toInvoice` field can take longer. This would cause the validation to execute before the `toggleIsToInvoice` finishes executing and then it would throw an error that the order was already finalized. This PR ads an extra wait on the `Invoice` button to make sure that the toggle is executed properly before finalizing the order. Runbot Error: [233024](https://runbot.odoo.com/odoo/runbot.build.error/233024) Task: [5897371](https://www.odoo.com/odoo/project/1737/tasks/5897371) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248191
This fix prevents Odoo module updates from failing when older or inconsistent field records are encountered. It safely skips incompatible field types during cleanup, improving update reliability without changing normal user workflows.
Original PR description
Description of the issue/feature this PR addresses: Fix AttributeError that occurs during module updates when processing selection field deletions. Current behavior before PR: When updating modules, an `AttributeError` occurs when trying to access the `ondelete` attribute on fields that are not Selection fields: AttributeError: 'Char' object has no attribute 'ondelete' Desired behavior after PR is merged: Add validation to check if the field type is 'selection' or 'reference' before attempting to access field.ondelete as a dictionary. Skip processing for incompatible field types to prevent AttributeError. @moduon MT-13588 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247971
This fixes an internal mismatch in the website page editor that could prevent certain invalid drop areas from being excluded correctly. No known customer issues were reported, but the change reduces the risk of unexpected editing behavior in future updates.
Original PR description
In [html_builder refactoring], `excludeNearParent` was passed to `getSelectorSiblings`, but `excludeParent` was expected, and so because of this, we couldn't exclude the parents where it wasn't possible to have a dropzone. Luckily, it wasn't used extensively, so no known issues were found, but this might have caused unexpected issues in future, so that's why it was renamed to `excludeParent` in order to work correctly. Button option tests were adapted as they had buttons directly inside of the .oe_structure, which shouldn't be allowed, so we had to wrap them in paragraph or div elements. [html_builder refactoring]: https://github.com/odoo/odoo/commit/9fe45e2b7ddb task-5932797
Fixed an issue in the HTML editor where the editing toolbar did not appear after triple-clicking text in list items that include icons. This makes editing marketing snippets and similar content more reliable for users.
Original PR description
Problem: When triple-clicking on text inside a list item that contains an icon, the toolbar is not shown. Cause: The toolbar is not displayed when the selection anchor node is inside an element with…
Problem: When triple-clicking on text inside a list item that contains an icon, the toolbar is not shown. Cause: The toolbar is not displayed when the selection anchor node is inside an element with `contenteditable="false"`. This happens in cases like: `<li><span class="…" contenteditable="false"></span>abc</li>` When triple-clicking on "abc", the selection anchorNode becomes the `span` and the offset is `0` and offset is "abc" offset 3. In that case, `selection.toString()` returns an empty string. While this may also be a browser related issue as the selection includes text but `toString()` still returns empty string, the root cause here is that normalization does not wrap the icon with `feff` because the corresponding selector is missing. Solution: Include icons under `li` elements when wrapping nodes with `feff`, so the selection is normalized correctly and the toolbar can be shown. Steps to reproduce: - Open Email Marketing. - Drop the "Comparison" snippet. - Triple-click on one of the texts with check icons. - Observe that the toolbar is not shown. task-5913202 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change adds automated checks to ensure customer loyalty points are not applied more than once when a point-of-sale order is saved as a draft or later cancelled. It helps protect loyalty balances from accidental inflation and improves confidence in POS loyalty workflows.
Original PR description
Step to reproduce: - have a trusted pos and a loyalty program which gives points per $ spent - start pos and select order and a partner (he should already have some LPs) - notice the loyalty points…
Step to reproduce:
- have a trusted pos and a loyalty program which gives points per $ spent
- start pos and select order and a partner (he should already have some LPs)
- notice the loyalty points assgined
- save the order, you are redirected to new order
- switch back to original order
Observation:
- Notice, the loyalty points are reassigned for example :
- if initially partner's LP = 50, product added is 100$ , LP = 50+100 = 150
- After saving, LP becomes 150 + 100 = 250
Cause:
- LP's are processed after every `sync_from_ui` call from `_postProcessLoyalty` which updates the customer's lp, even before the order is fullfilled or when order is still in `draft` state
Fix:
- Issue is fixed in https://github.com/odoo/odoo/commit/a4b37ec474656c7af23d0134251d589e9a6a61ca
- This commit adds related test for the fix
opw-5609964
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#248077
Forward-Port-Of: odoo/odoo#245400This change makes popover behavior consistent during automated testing by preventing rare timing-related animation issues. It helps reduce false test failures and supports more reliable delivery, without changing the user-facing product experience.
Original PR description
Because the popover had his animation enabled in tests, it could in very rare occasion end too fast and call it's finished callback, triggering extra repositionning (and thus extra expect.steps). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247341 Forward-Port-Of: odoo/odoo#244491
Calendar events created from a dragged time slot now keep the correct duration when users manually adjust the start or end time before saving. This prevents confusion later when opening the event for editing, where the duration now matches the time range users selected.
Original PR description
Currently, an incorrect duration is displayed when the start or end time is `manually changed` during event creation. **Steps to reproduce:** - Install the `Calendar` module and open the app. - Drag…
Currently, an incorrect duration is displayed when the start or end time is `manually changed` during event creation. **Steps to reproduce:** - Install the `Calendar` module and open the app. - Drag on the calendar to create a `2-hour` time slot (quick-create popup opens). - Manually adjust the start or end time to make the event `3 hours` long. - Click `Save & Close`. - Click on the event: it correctly displays (3 hours). - Click `Edit` and observe the `Duration` value. **Observation:** The duration field shows 2 hours instead of 3 hours. **Root cause:** - The `duration` field is not available (and therefore not stored) in the `quick-create view` at [1]. - When the `stop` time is set manually, the `duration` is computed at [2]. - When the `start` time is changed, the `stop` time is computed based on the previously computed `duration` at [3]. **Fix:** This commit adds the `duration` field to the `quick-create` view as `invisible` (preventing it from being recomputed on each onchange) and `force_save`. This aligns the behavior with `19.0` by preserving the last computed duration in the front-end model, as implemented in PR [4]. [1]: https://github.com/odoo/odoo/blob/84571c03ff38ee768ed135bef3afa98511e3ab7b/addons/calendar/views/calendar_views.xml#L294-L339 [2]: https://github.com/odoo/odoo/blob/84571c03ff38ee768ed135bef3afa98511e3ab7b/addons/calendar/models/calendar_event.py#L353-L356 [3]: https://github.com/odoo/odoo/blob/84571c03ff38ee768ed135bef3afa98511e3ab7b/addons/calendar/models/calendar_event.py#L358-L374 [4]: https://github.com/odoo/odoo/pull/226909 opw-5867946 Forward-Port-Of: odoo/odoo#247193
This update fixes an issue where the system incorrectly linked bank statement lines to the 'ODOO' partner. The change ensures that statement lines are now correctly associated with the appropriate partner, improving data accuracy and reporting. This resolves a potential error in how the Odoo bot was retrieving partner information.
Original PR description
When the partner_name was "ODOO" the retrieve partner was linking the statement line to OdooBot. no task id Forward-Port-Of: odoo/enterprise#106879
A test for the Shiprocket delivery module was failing due to a default pricelist being applied, which incorrectly inflated the total order amount. This fix ensures the test accurately reflects the expected tax calculation, preventing future issues with pricing.
Original PR description
Issue
-----
`File "/data/build/enterprise/delivery_shiprocket/tests/test_delivery_shiprocket.py", line 317, in test_shiprocket_delivery_with_discounts
self.assertAlmostEqual(sale_order.amount_total, 55)
AssertionError: 32.0 != 55 within 7 places (23.0 difference)
`
Cause
-----
Test fails because a pricelist gets applied by default and overrides the taxes.
-----
Error runbot 232692
Forward-Port-Of: odoo/enterprise#105180This update addresses a problem with our report testing process related to a temporary build environment (faketime). The report filter was malfunctioning due to how faketime interacts with the date filtering system. This fix ensures reports are tested correctly and avoids disruptions to the overall system.
Original PR description
Faketime doesn't integrate well with our current version of the report date filter. JS date is not frozen, so the filter misbehaves. It's working OK for all other builds. Future versions (19.2+) will probably have another version of the filter which should have a different implementation, solving the problem in another way. Reworked and backported from: odoo/enterprise#101689 Runbot error [link](https://runbot.odoo.com/odoo/error/234624) runbot-234624 Forward-Port-Of: odoo/enterprise#106172
This update fixes an issue preventing valid Zengin bank statement files from importing correctly. The validation process has been expanded to allow a wider range of characters, including standard hyphens and alphanumeric text, aligning with the Zengin specification. This ensures all valid bank statement files can now be imported into Odoo.
Original PR description
Before this commit, the Zengin file import validation was permitting only digits, spaces, and half-width Katakana characters. This limitation caused valid files to fail validation if they contained standard ASCII characters, such as the standard hyphen (which differs from the Katakana prolonged sound mark) or alphanumeric text. This commit updates the validation regex to support the full range of characters allowed by the Zengin specification. The allowed character set has been expanded to include: - Uppercase alphanumeric characters (A-Z, 0-9) - Standard symbols (e.g., -, ., /, (, ), etc.) Ref: https://bqa.smbc.co.jp/faq/show/2473?site_domain=web21lite task-5928087 Forward-Port-Of: odoo/enterprise#107007