Wednesday, September 16, 2026
11 changes · saas-19.4
Enhancements to existing features
The web debug menu now includes a Copy Arch button for the Computed Arch dialog, letting users copy the full computed view structure in one click. This makes troubleshooting, support sharing, and comparing customizations easier and less error-prone than manually selecting long XML text.
Original PR description
Description of the issue/feature this PR addresses: The "Computed Arch" debug dialog displays the fully computed view architecture, after inheritance, xpaths and studio customizations have been…
Description of the issue/feature this PR addresses: The "Computed Arch" debug dialog displays the fully computed view architecture, after inheritance, xpaths and studio customizations have been applied, in a read-only pre block. Extracting that text previously required manually selecting it in the browser, which is unreliable for long or deeply indented XML. Being able to copy this text to the clipboard helps with several common scenarios: - Debugging inherited views: when a view looks wrong and it is not clear which of several inheriting modules caused it, the computed arch can be diffed against the base view's arch to see exactly what changed. - Writing new xpath inherit rules: the exact final structure (attribute values, node ordering) is needed to write a correct expr="//field[@name='x']", which is easier to do in a scratch file or editor with search than by eyeballing a read-only dialog. - Bug reports and support tickets: the computed arch can be pasted into a Slack message, GitHub issue or support ticket so others can inspect the view without needing access to the database. - Studio customizations: consultants often need the underlying computed arch to understand why a Studio-added field appears in an unexpected position. - Comparing environments: the arch from a customer's staging instance can be diffed against production to spot config drift, e.g. a view customization made directly on prod. Current behavior before PR: In the "Computed Arch" debug dialog, the only way to get the arch text out of the browser is to manually click-drag to select it inside the pre block, then copy it. This is error-prone for long or deeply indented XML, where whitespace and line breaks are easy to select incorrectly or truncate. Desired behavior after PR is merged: A "Copy Arch" button is added next to "Close" in the dialog's footer. Clicking it copies the full computed arch to the clipboard in one click, with a brief "Copied" confirmation, removing the need to manually select the text. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#286797 Forward-Port-Of: odoo/odoo#286619
Resolved issues and error corrections
This fix keeps website builder automated tests reliable after a Chrome browser change altered how background image sizing values may be reported. It helps prevent false test failures during development and release validation, without changing the user-facing website builder experience.
Original PR description
In Chrome 152, single-value `background-size` properties may be serialized or expanded to include implicit dimensions (e.g., appending `auto` like `100px auto`), causing strict exact-string test assertions to fail. This commit updates `website` builder test expectations to use regex prefix matching or substring inclusion so tests remain reliable across different Chrome versions. Note: this is a followup of https://github.com/odoo/odoo/pull/285591 where I missed one occurence during forward-port. My bad. runbot-946570 Forward-Port-Of: odoo/odoo#288519
The mail recipient list now only counts followers who are subscribed to receive message updates. This prevents people who opted out of message notifications from appearing in the To line, making recipient information more accurate for users.
Original PR description
Before this commit, a follower not subscribed to "Messages" message subtype would still show up in the recipients list (the `To: ` line). This happens since [1] introduced the followers badge on the recipient list, without taking into account the subscription of the followers. This commit fixes the issue by using the `recipientsCount` field, which holds the count of followers subscribed to the "Messages" subtype (except self). [1] https://github.com/odoo/odoo/pull/255498 task-6545679
This update prevents product information popups from appearing accidentally when users scroll through products on touch devices. It improves the mobile Point of Sale experience by avoiding interruptions during normal browsing.
Original PR description
Steps to reproduce: - Open the PoS in mobile mode (touch device) - Swipe the product list up and down a few times Issue: The product info popup sometimes opens while scrolling, as if a product had been long pressed. Cause: Since the product card long press listens to pointerdown/pointerup, a touch that turns into a scroll ends with a pointercancel and never a pointerup, so the long press timer survives the gesture. The debounced onScroll handler is the only other canceller, but when the list is still scrolling from a previous swipe the debounce is already armed, its leading call is skipped and the continuous scroll events keep delaying the trailing call past the long press duration. Fix: Cancel the long press on pointercancel, like pointerup. opw-6514079 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#287835
The call settings menu now shows the correct name for the selected audio output device when input and output devices share the same browser device ID. This prevents confusion for users choosing microphones and speakers in Odoo calls, especially in Chrome setups where default devices can overlap.
Original PR description
Steps to reproduce: - Have an input audio device and an output audio device with different names but same device ID. Using Chrome, if the OS only sees one of each, both should have "default" as device ID. (alternatively, modify the code at `updateDevicesList` to simulate having devices of that kind). - Select those devices in the call settings UI, then open the settings UI dropdown again. => The "input" device is properly shown but the "output" device shows the "input" device names (while in fact this is the right one selected in the inner dropdown). This happens since [1]. Before that there were native `<select>` nodes that filtered devices by kind before rendering each option, and the "default" value of Chrome was not really handled. [1]: https://github.com/odoo/odoo/commit/93d0931fba1f467de265200b6a0463cf7edf9534 Related to task-6533808 Forward-Port-Of: odoo/odoo#288434 Forward-Port-Of: odoo/odoo#288285
The equipment section on planning slots now opens in a card-style view on mobile devices instead of a list. This makes it easier for field service teams to review equipment details on smaller screens.
Original PR description
This commit makes sure that the kanban view is used in mobile (over the list view) for the equipment notebook on planning slots. task-6492979
This fix prevents an error when users open sale or purchase receipt records from Invoice Analysis. It ensures receipt data is handled consistently in reporting, so teams can review confirmed receipts without interruption.
Original PR description
When enabling Sale/Purchase Receipts and trying to open the form view from Invoice Analysis, an error occurs. The issue is caused by the `move_type` used in `_where()`, which includes a type that is not defined in the `move_type` field selection. Steps to reproduce: - Enable Sale/Purchase Receipts. - Create a Sale/Purchase Receipt for partner A and confirm it - Go to Invoice Analysis and open the Pivot view - Click on a cell to open partner A's receipt, then try to open the form view - Error Ticket [link](https://www.odoo.com/odoo/project.task/6462153) opw-6462153 Forward-Port-Of: odoo/odoo#288077 Forward-Port-Of: odoo/odoo#282922
Subscription invoices now use the earliest deferred start date across invoice lines when setting subscription or upsell log dates. This prevents later invoice lines from incorrectly overriding the effective date, improving accuracy for subscription records and related reporting.
Original PR description
When posting a subscription invoice, each invoice line overwrites the effective date of the subscription or upsell logs. The last line therefore determines the date, even when another line has an earlier deferred start. Use the earliest deferred start date on the invoice, falling back to the invoice date when no deferred start date is set. Forward-Port-Of: odoo/enterprise#131512
The accounting dashboard payment button now excludes payments that have already been reconciled. This helps users focus only on payments that still need action and avoids confusion from showing completed items as ready to pay.
Original PR description
In the accounting dashboard, we have a button to show payments ready to be paid, but we don't exclude the reconciled payments from this view. We should as reconciled payment are supposed to be paid. task-6564159 Forward-Port-Of: odoo/enterprise#131143
Fixed an issue where Save and Discard buttons could remain visible after a user retyped a value that looked different but was treated as unchanged. This ensures forms correctly show when there is nothing left to save, reducing confusion and unnecessary page reloads.
Original PR description
**Description of the issue/feature this PR addresses:** Fixes #287978 In `useInputField` (`input_field_hook.js`), `onChange` and `commitChanges` only trigger the `FIELD_IS_DIRTY` bus event with…
**Description of the issue/feature this PR addresses:** Fixes #287978 In `useInputField` (`input_field_hook.js`), `onChange` and `commitChanges` only trigger the `FIELD_IS_DIRTY` bus event with `false` when the newly typed value actually differs from the value already stored on the record. When the typed text parses to the *same* value as what is already on the record (e.g. retyping `6,250` after the field already holds `6,25`), the code takes the `else` branch, which only resets the displayed text and never notifies the bus that the field is no longer dirty. `form_status_indicator.js` keeps whatever `fieldIsDirty` state it last received from that bus event, and shows the Save/Discard buttons whenever `root.dirty || fieldIsDirty`. Since nothing ever fires `FIELD_IS_DIRTY(false)` in that `else` branch, `fieldIsDirty` stays stuck at `true`. `Discard` correctly resets `root.dirty`, but has no way to reset `fieldIsDirty`, so the Save/Discard buttons keep showing even though the record is clean. **Current behavior before PR:** 1. Edit a field to a new value, click away (value committed, indicator shows Save/Discard as expected). 2. Edit the same field again, this time typing different text that parses to the *same* value (e.g. `1.20` when the field already holds `1.2`), click away. 3. Click **Discard**. The record is reverted, but the Save/Discard buttons remain visible. They stay stuck until the page is reloaded. **Desired behavior after PR is merged:** Retyping different text that parses to the same value clears the field's dirty state like any other case where the field ends up unchanged, so Discard (or any other action) correctly hides the Save/Discard buttons once there is nothing left to save. Forward-Port-Of: odoo/odoo#288030
This fixes an automated Point of Sale test for QFPay payments so it follows the updated checkout flow and clicks the Send button before waiting for card payment. It helps ensure QFPay terminal payment flows are properly tested and avoids false test failures.
Original PR description
Commit 7a208335fa84 ("[IMP] point_of_sale: avoid fast payments") removed the automatic sending of the transaction to the terminal, so the user now has to click on "Send" to trigger the payment request.
The tours of the other payment terminals (adyen, razorpay, safaricom, viva_com) were adapted accordingly, but pos_qfpay was missed. As a result, the payment line never reaches the 'waitingCard' status and the tour times out waiting for the "Waiting for card" step.
Add the missing PaymentScreen.clickSendButton() step to fix the tour.
runbot-940270
Forward-Port-Of: odoo/odoo#288301
Forward-Port-Of: odoo/odoo#275204