Thursday, August 20, 2026
15 changes · saas-19.2
Enhancements to existing features
This change gives Odoo's web test helpers more time to detect expected page updates, matching other existing test waits. It reduces false test failures on slower or heavily loaded machines without affecting successful test speed.
Original PR description
Before this commit, waitFor, waitForNone and waitUntil gave the DOM 200 milliseconds, which the loop turns into 12 animation frames, while contains() and expect.waitForSteps sitting in the same tests…
Before this commit, waitFor, waitForNone and waitUntil gave the DOM 200 milliseconds, which the loop turns into 12 animation frames, while contains() and expect.waitForSteps sitting in the same tests give 10 seconds. 430 call sites in addons reach these three helpers and 29 pass an explicit timeout, so 12 frames is what the other 401 get. The problem is that 12 frames is less than what the client needs on a loaded machine. Measured on "should remove file from html editor if removed from attachment list", on the wait that follows the Full composer button: - 5 to 7 frames on an idle machine; - 11 to 18 frames over 8 runs with the machine at load 10 to 20, 5 of the 8 above the 12 frames the default allows. Those 5 are failing runs, and the same test at load 13 to 29 fails 6 runs out of 6 with the 200 milliseconds, 0 out of 6 with 10 seconds. Note that a longer timeout costs nothing on a green build: the wait ends on the frame the DOM matches, so it only delays the report of a test that was going to fail anyway. Hoot fails the test itself after 5 seconds, 15 in test_js.py, which keeps bounding a wait that never resolves. This commit raises the default to 10 seconds, the delay a tour step already gets in macro.js and the one contains() and expect.waitForSteps already have. https://runbot.odoo.com/odoo/error/946094 Forward-Port-Of: odoo/odoo#282702
Resolved issues and error corrections
Peppol invoice XML now uses the reference from the actual invoice contact when one is set, instead of incorrectly taking the parent company reference. This helps ensure e-invoices contain the buyer information expected by customers and receiving systems.
Original PR description
**Steps to reproduce:**
* Set up a French company and configure Peppol E-invoicing.
* Install `account_edi_ubl_cii` module.
* Create a company partner (customer) and set a **Reference** value on the company contact under
**Customer** -> **Settings** -> **Sales and Purchase**.
* Create a child contact under that company and set a different Reference value.
* Create an invoice using the child contact as the invoice partner and confirm the invoice.
* Send it via Peppol.
**Observed Behaviour:**
* The BuyerReference in the generated XML contains the reference of the parent
(commercial partner) Instead of the child contact used on the invoice.
**Cause:**
* The buyer reference was taken from the commercial partner instead of the
invoice partner.
**Fix:**
* Update the condition to use the invoice partner's reference when available;
Otherwise, fall back on the commercial partner's reference.
opw - 6330649
Forward-Port-Of: odoo/odoo#273700Point of Sale receipts now show the correct rounding line when a customer overpays in cash. This keeps receipt totals clear and consistent with normal rounded payments, reducing confusion for staff and customers.
Original PR description
**Steps to reproduce:** - Make a rounding method, Nearest and 0.05 of rounding - Make a product that costs $4.99, don't set a tax - Go to the PoS - Order the product - Before paying click the +10…
**Steps to reproduce:** - Make a rounding method, Nearest and 0.05 of rounding - Make a product that costs $4.99, don't set a tax - Go to the PoS - Order the product - Before paying click the +10 button, then pay - The rounding line is not present on the ticket **Why the fix:** When making a normal rounded purchase, by just clicking the "Cash" button, the rounding line will be displayed. This is because we do not try to apply the rounding if the rounding of the remaining is not equal to zero. https://github.com/odoo/odoo/blob/995629db3231de944710751c3184bf1b8b1355c7/addons/point_of_sale/static/src/app/models/accounting/pos_order_accounting.js#L118-L123 When we try to over pay, the remaining will be negative by the amount we overpay, so the amount will be set to zero, and the rounding will not be set. We now take the amount we overpay into account, and deduct it from the amount we paid to then correctly compute the remaining amount without having to deal with the amount overpaid. Some tests were not taking the rounding as it was not working correctly, so it has now been changed now that it works as it should. opw-6025807 Forward-Port-Of: odoo/odoo#256117
Changing the project on timesheet entries through mass edits or automated updates now clears any task that does not belong to the new project. This prevents inconsistent timesheet data and helps keep reporting and billing information accurate.
Original PR description
When modifying project_id on a timesheet through mass edit/rpc or anything that is not triggering `onChange`. The task_id would not be reset if it doesnt' belong to the new project set on the timesheet. Steps to reproduce: ------------------- * Install studio for easier reproducing of the issue * Open the timesheet list view * Open studio and activate the mass edit on the view * Modify the project_id on multiple records > Observation: The task_id stays the same even if they do not belong to the new set project Why the fix: ------------ Instead of relying only on the onChange we add an inverse to the project_id that will reset the task when needed. opw-6259149 Forward-Port-Of: odoo/odoo#278287
This fix prevents temporary wizard records from being offered in tracking reference selections. It keeps sales and marketing attribution choices cleaner and avoids users selecting records that should not be used for ongoing tracking.
Original PR description
Various places mistakenly used `model.is_transient()` to filter the transient models, where the model is `ir.model` record itself, which always returns False since `ir.model` is a regular persistent model. As a result, transient models (wizards) were never filtered out and allowed into the `utm_reference` Reference field selection. This commit fixes it by using `self.env[model.model].is_transient()` to call `is_transient` on the actual model. Task-6458883
This update prevents an automated animated GIF image test from failing on Ubuntu Jammy by using an image setting supported across Pillow versions. It helps keep Odoo's base platform tests reliable across supported environments without changing user-facing behavior.
Original PR description
`Image.Palette.ADAPTIVE` is not available in the Pillow version provided by Ubuntu Jammy, causing the animated GIF test to fail. Use `Image.ADAPTIVE` instead, which is compatible with both older and newer Pillow versions. 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#282223
This fixes issues in Odoo's JSON logging so ignored fields and test-related information are handled correctly. It also adds safeguards through tests and makes it easier to include extra log details without replacing the default setup.
Original PR description
The JsonFormatter has two bugs - the ignore list is not working as expected - in 18.0-18.4 the 'test' key is broken This commit add tests to ensure those behavior works as expected While on it, also…
The JsonFormatter has two bugs - the ignore list is not working as expected - in 18.0-18.4 the 'test' key is broken This commit add tests to ensure those behavior works as expected While on it, also adds a `additional_record_keys` parameter to allow to specifically add keys to the default list, without having to override the whole list, and add additional default keys (exc_info and test) The previous `ignored_record_keys` default value was possible to remove by calling `JSONFormatter(ignore_record_keys=[])` The purpose was to be able to easily include all keys and ignore the default ingnore list, but this makes the additional blacklisting of a few keys more tedious, and the general usage and implementation more complex `JSONFormatter(ignore_record_keys=[*JSONFormatter.DEFAULT_IGNORED_RECORD_KEYS, 'other key'])` To simplify the logic, **this is not the case anymore**, so to include all keys something like this would be needed `JSONFormatter(additional_record_keys=JSONFormatter.DEFAULT_IGNORED_RECORD_KEYS)` Or an hardcoded list. Forward-Port-Of: odoo/odoo#281449 Forward-Port-Of: odoo/odoo#279049
This fix ensures Razorpay payment captures and refunds use the correct original transaction reference. It helps prevent failed or mismatched follow-up payment operations, improving reliability for businesses using Razorpay.
Original PR description
Forward-Port-Of: odoo/odoo#282554
This fix makes an internal mail test wait until all expected peer connections are fully established before checking the result. It reduces random test failures on busy machines, helping keep the mail system validation stable without changing user-facing behavior.
Original PR description
Before this commit, "mesh peer to peer connections" fails at random on a loaded machine, counting fewer connections than its ten users make:
[toBe] expected values to be strictly equal
> Expected: 90
> Received: 81
This happens because the test counts the peers as soon as its addPeer calls resolve. addPeer awaits the readiness promise of the peer, which also resolves, with false, when that peer is disconnected. A connection slow to open reaches the recovery watchdog, which tells the other side to drop the peer, drops it locally and adds it back without awaiting it. The awaited promises can therefore all be settled while recovered peers are still connecting.
This commit waits for the mesh to reach its full size before counting, so that a recovery in flight no longer decides the result. With the browser CPU throttled, the test fails about half of its runs before this commit, and none after.
Forward-Port-Of: odoo/odoo#282719Mexican payroll processing no longer crashes when a company has no VAT or tax ID recorded. This helps payroll users continue reviewing payslips and receive warnings instead of being blocked by an error.
Original PR description
`res.company.vat` is not required and can be `False`. Guard the `len()` call so `_issue_mx_warnings` doesn't crash on payslips for companies without a VAT set.
```py
File "/home/odoo/src/enterprise/saas-19.3/hr_payroll/models/hr_payslip.py", line 1936, in _compute_issues
issues = generate_issue(slip, context)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/enterprise/saas-19.3/l10n_mx_hr_payroll_account_edi/models/hr_payslip.py", line 235, in _issue_mx_warnings
if not slip.company_id.l10n_mx_curp and slip._l10n_mx_is_curp_needed():
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/enterprise/saas-19.3/l10n_mx_hr_payroll_account_edi/models/hr_payslip.py", line 325, in _l10n_mx_is_curp_needed
or len(self.company_id.vat) == 13
^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: object of type 'bool' has no len()
```
Forward-Port-Of: odoo/enterprise#128216The SMS Marketing editor now hides the Insert Field option when a message can no longer be edited. This prevents users from hitting an error when viewing SMS campaigns in sent or sending stages.
Original PR description
Steps to reproduce ---------------------------------------- 1. Install the SMS Marketing module (mass_mailing_sms). 2. Open any SMS Marketing record in the "Sent" or "Sending" stage. 3. Click on the…
Steps to reproduce ---------------------------------------- 1. Install the SMS Marketing module (mass_mailing_sms). 2. Open any SMS Marketing record in the "Sent" or "Sending" stage. 3. Click on the "Insert Field" button. Observation ---------------------------------------- Traceback Occurs: ``` TypeError: Cannot read properties of null (reading 'getRootNode') ``` Issue ---------------------------------------- The SMS widget displays the "Insert Field" button even when the SMS message field is readonly. The button relies on the textarea reference to open the dynamic fields popover, but the textarea is only rendered in editable mode. The readonly behavior of the text field can be seen here: https://github.com/odoo/odoo/blob/ccce9fcc79edcfb1f310b49a16de8235d987b74b/addons/web/static/src/views/fields/text/text_field.xml#L5-L7 However, the SMS widget still renders the "Insert Field" button without checking whether the message field is readonly: https://github.com/odoo/odoo/blob/ccce9fcc79edcfb1f310b49a16de8235d987b/addons/sms/static/src/components/sms_widget/fields_sms_widget.xml#L6 As a result, clicking the button in readonly mode tries to access an unavailable textarea reference to open the dynamic fields popover, causing a traceback. Solution ---------------------------------------- Hide the "Insert Field" button when the SMS message field is readonly, preventing the dynamic fields popover from being opened when the textarea reference is unavailable. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#282845
Database neutralization for TikTok Shop data no longer fails when multiple active shops exist. The cleanup now removes real shop references while keeping each record unique, helping copied or test databases be prepared without interruption.
Original PR description
Steps to produce: --- - Install sale_tiktok module. - Create two active tiktok.shop records. - Run the database neutralization command. Issue: --- - Neutralization fails with a PostgreSQL error:…
Steps to produce: --- - Install sale_tiktok module. - Create two active tiktok.shop records. - Run the database neutralization command. Issue: --- - Neutralization fails with a PostgreSQL error: ```py duplicate key value violates unique constraint tiktok_shop_unique_active_shop` DETAIL: Key (tiktok_shop_ref)=(1) already exists. ``` Root cause: --- - At [1], we are setting `tiktok_shop_ref = 1` for all `tiktok_shop` records. Because `tiktok_shop` enforces a partial unique constraint on `tiktok_shop_ref` for active shops [2], setting the same reference value `1` on multiple active shops violates this constraint. Solution: --- - Update sql to assign a row-unique string to each shop. This strips the real shop reference while maintaining uniqueness across active shop records so neutralization completes cleanly. [1]https://github.com/odoo/enterprise/blob/85754b0354b76da8b4d87a3a81dd19679ed35d15/sale_tiktok/data/neutralize.sql#L1-L8 [2]https://github.com/odoo/enterprise/blob/85754b0354b76da8b4d87a3a81dd19679ed35d15/sale_tiktok/models/tiktok_shop.py#L136-L139 opw-6451715 --- Forward-Port-Of: odoo/enterprise#127532
Fixed an issue in the Timesheet Assistant where selecting a project-only suggestion could unexpectedly reuse a recent task. Timesheets now keep the task field empty when the suggestion has no task, improving accuracy and reducing manual corrections.
Original PR description
Steps to reproduce: - - Open the Timesheet Assistant. - Select a suggestion matched to a project but without a task. - Select a second suggestion from the same project. Issue: - A recently used task is automatically assigned to the timesheet even though the selected suggestion does not contain a task. Cause: - When updating the existing timesheet form, only `project_id` was passed. This triggered the project onchange with the `timesheet_timer_search` context, which automatically selected the most recently used task. Solution: - Always pass `task_id` when updating the form, even when it is empty. This prevents the project from being updated alone and avoids the automatic task assignment. task-6462495
Fixed a display issue in the website theme preset preview where title text could appear at the wrong size. This helps users see a more accurate preview when choosing or adjusting a website theme.
Original PR description
When the conflict of the forward port [1] was resolved, an error was introduced when the class `fs-4` was replaced by `fs-h4`. This commit fixes the class. [1] https://github.com/odoo/odoo/pull/279324
This fix prevents the HTML editor from incorrectly applying an outer table's text or background color to tables nested inside it. Users who create or edit nested tables will keep the intended separate colors, improving visual accuracy in edited content.
Original PR description
Problem: When a `table` with a `color`/`backgroundColor` contains a nested `table`, `distributeTableColorsToAllCells` propagates the outer table's color to every `td` in the subtree, including cells…
Problem:
When a `table` with a `color`/`backgroundColor` contains a nested `table`, `distributeTableColorsToAllCells` propagates the outer table's color to every `td` in the subtree, including cells belonging to the inner table. The inner table's own color is then discarded since its `td`s already have a value.
Cause:
`table.querySelectorAll("td")` returns every `td` in the entire subtree, not just the table's own direct cells.
Solution:
Scope the selected `td`s to `td.closest("table") === table`, so a table's color is only distributed to its own cells.
Steps to reproduce:
1. Add a `background-color` to an outer `table`.
2. Nest a `table` with a different `background-color` inside one of its cells.
3. Load/normalize the content in the editor.
4. Observe both tables' cells carry the outer table's color.
opw-6438972
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#281850
Forward-Port-Of: odoo/odoo#281413