Friday, October 17, 2025
6 changes · 17.0
Enhancements to existing features
This update makes automated test browser shutdown more resilient when Chrome reports rare shutdown errors. It helps prevent stalled build environments and leftover browser processes, improving reliability for the development and testing pipeline.
Original PR description
In some instances, Chrome can apparently fail CDTP calls with "Execution context was destroyed". According to the internet this mostly happens because of navigation events, here it's not clear if…
In some instances, Chrome can apparently fail CDTP calls with "Execution context was destroyed". According to the internet this mostly happens because of navigation events, here it's not clear if this is in response to `stop`-ing the page, or a pre-existing navigation directive interfereing with the stop-ing of the browser. I tried reproducing locally under the assumption that the `Page.stopLoading` might be the cause but got nowhere[^1]. This issue seems extremely infrequent, and in most cases is but a minor annoyance, an error appears on the corresponding build, and that's it. However if the error occurs during `ChromeBrowser.stop` then the browser is not terminated, which on runbot prevents the docker image from shutting down properly, and leaves zombie builds. Therefore make `ChromeBrowser.stop` more resilient to errors in the initial section so that we do terminate the browser even if the "graceful CDTP shutdown" fails. While at it, add a fallback to kill the browser if it does not terminate gracefully. https://runbot.odoo.com/odoo/error/233442 [^1]: and the error only happening in 18.0 and later when `Page.stopLoading` was present long before that makes it likely the proximal cause is in the code being run, especially as all the errors sampled from the builds list are related to pos and the failure are immediately preceded by ongoing HTTP requests
Resolved issues and error corrections
This fix ensures Swiss payroll ELM transmission employee views behave correctly when payroll is used across multiple companies or countries. It helps prevent confusion or incorrect field visibility for businesses managing Swiss payroll in broader company setups.
Original PR description
task-5159023
Invoice emails now keep a consistent language for all recipients, including contacts copied on the message. This prevents mixed-language wording in invoice email headers, improving clarity and professionalism for multilingual customer communications.
Original PR description
**Steps to reproduce:** - Install Accounting and Contacts - Go to "Settings / Translations / Languages" - Activate another language (e.g. French) - Create a contact with an email and French as…
**Steps to reproduce:** - Install Accounting and Contacts - Go to "Settings / Translations / Languages" - Activate another language (e.g. French) - Create a contact with an email and French as language - Create another contact with an email and English as language - Go to "Settings / Technical / Email / Email Templates" - Edit "Invoice: Sending" email template - In "Email Configuration" tab, add the email of the English contact in "Cc" field - Create an invoice for the French contact - Confirm the invoice - Send the invoice **Issue:** The invoice is sent by email to the customer and to the email configured as CC in the template. Both emails are in French, but some terms in the email header for the CC contact are in his configured language. For example, instead of "Voir Facture", it's written "View Facture". And instead of "$10 dû le 01/01/2025", it's written "$10 due 01/01/2025". **Cause:** The content of the email and the model description is translated in the language of the customer of the invoice. However, when grouping the recipients of the email, they are grouped by their language, leading to a mix of languages for some recipients. **Solution:** In the method grouping the recipients by lang, there is a parameter named "force_email_lang" that is the lang used for the content of the email, but it is only used as a fallback when a recipient doesn't have a lang configured. From the name of the parameter (i.e. force_email_lang), it should be use in priority if set. opw-4904029 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a browser error that could appear after saving a pop-up detail form from a repair order parts list. The change helps keep the interface stable when users open and close related record dialogs, reducing confusing console errors and potential interruptions.
Original PR description
Steps to Reproduce: - Open a Repair Order form view in Odoo 17 or 18. - Navigate to the Parts tab. - In the list view of parts, click the Smart Button on any part line. - A pop-up form view opens…
Steps to Reproduce:
- Open a Repair Order form view in Odoo 17 or 18.
- Navigate to the Parts tab.
- In the list view of parts, click the Smart Button on any part line.
- A pop-up form view opens showing detailed operations.
- Click the “Pick From” field value, but don't change its value.
- Click the Save button in the pop-up.
- Observe the browser console for the error: TypeError: Cannot read properties of null (reading 'querySelector') at ListRenderer.focusCell
Traceback:
```py
TypeError: Cannot read properties of null (reading 'querySelector')
at ListRenderer.focusCell (https://91307582-17-0-all.runbot219.odoo.com/web/assets/15b4f47/web.assets_web.min.js:9519:80)
at ListRenderer.<anonymous> (https://91307582-17-0-all.runbot219.odoo.com/web/assets/15b4f47/web.assets_web.min.js:9477:272)
```
Root Cause:
- Asynchronous patching in OWL (onPatched with await Promise.resolve()) continues execution after the next tick, even if the component is destroyed.
- When the component is destroyed, OWL sets status(this) = 3 (DESTROYED).
- focusCell() accesses DOM using querySelector, which fails if the component is destroyed.
- The code did not check the component status before calling focusCell().
Fix:
- Added `if (status(this) === destroyed) return;` to stop focusCell() execution on destroyed components.
- Ensured async patching is handled safely with await Promise.resolve().
- Added `onWillDestroy` to clean up dialog callbacks, preventing memory leaks.
OPW - [5154694](https://www.odoo.com/odoo/project/70/tasks/5154694)
[PAD](https://pad.odoo.com/p/issue_5154694_shku)
Localhost issue reproduction [steps](https://drive.google.com/file/d/1wkglUosOveUseU0mBePZcQAFB_ZWr3uM/view)
17:https://github.com/odoo/odoo/blob/f9726cfe93e8850a38d9de06acfa5d78473b50b0/addons/web/static/src/views/list/list_renderer.js#L223
18:https://github.com/odoo/odoo/blob/1cac54db8634267a780b4011291f1e8a80ac5f5b/addons/web/static/src/views/list/list_renderer.js#L213
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-prRefreshing appointments filtered by staff member no longer causes an error when the system checks available capacity. This helps staff and customers continue booking or managing appointments without interruption.
Original PR description
This commit fixes an issue where the refresh with appointment based on staff user was raising a traceback as it also tried to compute the max capacity possible. Related commit 3cca7e47ab58f8a7d4e9196dbf60f7068348216b task-5118860
This change removes an unnecessary browser setting from Point of Sale IoT device requests. It helps avoid errors for users on older Chrome versions while keeping local device communication working as expected.
Original PR description
This reverts commit 1a934ae which added the `"targetAddressSpace": local` option to IoT fetch requests. This is because of two reasons: 1. It caused errors on older versions of Chrome that implemented the obsoleted 'Private Network Access' standard. 2. It was not actually required in the first place, it is only needed in situations where a HTTP resource is accessed from HTTPS using a domain that resolves to a local IP. In Odoo we only ever do this for HTTPS -> HTTPS requests, where it works automatically. task-5157145 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr