Thursday, August 27, 2026
10 changes · 18.0
Enhancements to existing features
The mail test suite now re-checks certain pending conditions more frequently instead of waiting up to 10 seconds. This reduces unnecessary waiting in automated testing, helping developers get feedback faster without changing user-facing behavior.
Original PR description
Before this commit, a contains that does not match right away runs again only when its MutationObserver fires, and once more at the 10 seconds timeout. The problem is that the observer reports neither a text node updated in place nor an input value or checked property, so a check waiting for one of those sleeps 10 seconds and then passes: "Delete starred message decrements starred counter once" spends 10.2s of the 183s @mail suite waiting for a counter to go from "Starred3" to "Starred2". This commit turns that single timeout into a 500ms tick up to the same deadline, so that such a check costs 500ms. The tick uses the unmocked timer to stay out of the timer graph a test drives with runAllTimers, and only 32 of the suite's 4239 contains calls stay pending long enough to tick once.
The web test runner now avoids unnecessary memory cleanup pauses unless memory use is actually high. This reduces wasted time during automated testing while keeping the existing safety behavior for browsers that cannot report memory usage.
Original PR description
Before this commit, the unit test runner pauses for a major garbage collection after every test file, since __gcAndLogMemory collects whenever window.gc exists and browser_js always passes --js-flags=--expose-gc. The problem is that the heap it protects stays at 183MB of a 4192MB limit, so those collections reclaim nothing: the 84 of an @mail run cost 8.8s of its 183s, and the whole suite has 1268 test files. This commit turns the unconditional collection into one that runs only past half the limit, so that a run pays for it when the heap really grows. A browser without performance.memory keeps collecting after every file.
The live chat settings now explain that automatic chat popups only open on larger screens. This helps teams understand why mobile visitors see the chat button instead of an automatically opened chat window during testing or rollout.
Original PR description
The 'Open automatically' action only triggers the auto popup on larger screens (`ui.isSmall` is checked in `AutopopupService. allowAutoPopup`). On mobile/small viewports, only the chat button is shown and the visitor must tap it manually. The existing help text does not mention this, which could lead to confusion when the auto popup does not trigger during testing on mobile. Update the field's help text to explicitly state that automatic opening is limited to larger screens. opw-6459279 Forward-Port-Of: odoo/odoo#284785
Resolved issues and error corrections
This fixes a small display issue in the website shop cart where an internal placeholder could appear as an unintended page style marker. The change keeps cart line styling clean and consistent, with no change to shopping cart behavior or checkout flow.
Original PR description
The t-attf-class expression on the cart product line used the Python 'and' operator without a fallback: 'line.linked_line_id and "optional_product info"'. When linked_line_id is an empty recordset (falsy), Python's 'and' returns the falsy operand itself instead of an empty string. QWeb then interpolates that operand into the class attribute via str(), rendering the literal 'sale.order.line()' as a CSS class on every cart line without a linked_line_id. Adding 'or ...""' forces the expression to fall back to an empty string when linked_line_id is falsy, restoring correct conditional class rendering consistent with the adjacent attrs in the same t-attf-class. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#284835
Documentation and clarification updates
Shinnosuke Morita has been added to Quartile's corporate contributor license agreement list. This is a legal/administrative update that helps confirm contribution authorization and has no impact on product functionality.
Original PR description
Adding myself to the Quartile corporate CLA contributors list. Related: https://github.com/odoo/enterprise/pull/129459
This fix ensures the Urban Piper point-of-sale integration is removed and restored together with the related enterprise point-of-sale component. It prevents reinstall errors that could interrupt system maintenance or module updates.
Original PR description
Problem: Uninstalling and reinstalling `web_enterprise` causes a ParseError on the `res.config.settings` view when `mail_mobile` (or another module) is loaded. Cause: `pos_urban_piper` inherits `res.config.settings` and targets the setting block `urban_piper_setting`, which is defined in `pos_enterprise`. However, `pos_urban_piper` only declared a dependency on `pos_preparation_display`. When `web_enterprise` is uninstalled, `pos_enterprise` is uninstalled as a cascade, but `pos_urban_piper` stays installed. This leaves an orphaned inherited view targeting an anchor that no longer exists. On the reinstall pass, loading views revalidates the inheritance tree before `pos_enterprise` is reloaded, causing a ParseError. Fix: Add `pos_enterprise` to `pos_urban_piper`'s manifest dependencies so `pos_urban_piper` is uninstalled and reinstalled together with the module owning its view anchor. runbot-234911
The Shop Floor view now disables the gear menu while opening a Manufacturing Order, preventing users from launching another dialog during the transition. This avoids a disruptive error on slower connections and makes navigation from work orders more reliable.
Original PR description
**Steps to reproduce:** * Install the **Manufacturing** module with **Work Orders** enabled. * Create and confirm a Manufacturing Order with at least one Work Order. * Open the **Shop Floor** view. *…
**Steps to reproduce:** * Install the **Manufacturing** module with **Work Orders** enabled. * Create and confirm a Manufacturing Order with at least one Work Order. * Open the **Shop Floor** view. * On a work order card, click the **gear** icon to open the menu dialog. * Click **Open Manufacturing Order** on a slow network connection. * Before the MO form view finishes loading, quickly click the **gear** icon again and open another dialog (e.g. Log Note). * The MO form view loads, destroying the shop floor component. * Close the Log Note dialog. **Observed behavior:** * An `UncaughtPromiseError: Component is destroyed` error is thrown because the dialog tries to interact with the shop floor component that has already been destroyed by the navigation to the MO form view. **Cause:** * When the user clicks "Open Manufacturing Order", `doAction` is called to navigate to the MO form view, and `props.close()` immediately closes the menu dialog. However, the shop floor component is still visible while the new view is loading. * During this gap, the gear button remains clickable. If the user opens another dialog (e.g. Log Note), that dialog holds a reference to the shop floor component. When the MO form view finishes mounting, the shop floor is destroyed, and closing the stale dialog triggers operations on the destroyed component. **Fix:** * Add an `actionPending` state flag to `MrpDisplayRecord`. When the user selects "Open Manufacturing Order" from the menu dialog, an `onSelect` callback sets `actionPending` to `true`, which disables the gear button and prevents any new dialog from being opened. * The flag is only set for `openMO` (which navigates away and destroys the component), not for other menu actions like Scrap, Add Component, or Log Note which open wizard dialogs and return to the shop floor. opw-6107579
The French PDP registration wizard no longer shows “(Production)” when the system is already in production mode. This avoids redundant wording and makes the registration screen clearer for users.
Original PR description
It makes no sense to mention (Production) on pdp registration wizard when you are in prod mode Forward-Port-Of: odoo/odoo#280360
The inventory report now keeps its table layout aligned when warehouse locations are grouped. This prevents missing gridlines and broken borders in printed PDF reports, making inventory counts easier to read and share.
Original PR description
When new columns were added to the stock inventory report, the location grouping row was not updated. This results in mismatched column counts, causing missing gridlines and broken borders in the PDF output Fixed by ensuring the location row's column count matches the header <img width="603" height="200" alt="image" src="https://github.com/user-attachments/assets/86872bee-f315-4bdd-b3f2-a525e3bb5fe0" /> ### Steps to reproduce: - Ensure warehouses are activated in the settings - Go to Barcode -> Count Inventory - Add a Product - Select the gear Icon then "Print Inventory" - You will notice that the location row has missing gridlines opw-6307728
This fixes a configuration typo that prevented two important accounting report templates from being properly protected against deletion. The change helps keep standard vendor bill and invoice reports available and reduces the risk of accidental removal.
Original PR description
On `ir.actions.report` we want to block the unlinking of specific reports in odoo. However, when the list was created a comma was missed between `action_account_original_vendor_bill` and `account_invoice_without_payment` which means we were actually protecting against people unlinking `action_account_original_vendor_billaccount_invoice_without_payment`. Adding in that comma will allow these two records to be properly protected. task-none Forward-Port-Of: odoo/odoo#283323