Thursday, August 27, 2026
6 changes · 18.0
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
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