Thursday, September 25, 2025
5 changes · 18.0
Resolved issues and error corrections
The online shop now updates available quantities correctly when customers add either a kit product or one of its components to their cart. This prevents shoppers from seeing misleading stock information and helps avoid overselling when kit items share limited inventory with individual products.
Original PR description
### Steps to reproduce: - In the settings website > Shop: - Disable `Out-of-Stock: Continue Selling`. - Enable `Show Available Qty` if below 5 units. - Create 2 storable products published on the…
### Steps to reproduce:
- In the settings website > Shop:
- Disable `Out-of-Stock: Continue Selling`.
- Enable `Show Available Qty` if below 5 units.
- Create 2 storable products published on the website:
- COMP, put 1 unit in stock.
- KIT with bom of type Kit using 1 x COMP.
- With a private window go to the shop.
- Add 1 x COMP or KIT to the chart.
#### > This is not reflected on the available quantity in stock of the other product
### Cause of the issue:
The availability on the website is computed from the product availability using the `free_qty` fetched because of this override: https://github.com/odoo/odoo/blob/d358542c9159f325b4e2ff184ed1f5cdb6b8c5a9/addons/website_sale_stock/controllers/variant.py#L10-L13 from which the cart quantity of the product itself is deduced before re-render:
https://github.com/odoo/odoo/blob/d358542c9159f325b4e2ff184ed1f5cdb6b8c5a9/addons/website_sale_stock/static/src/js/variant_mixin.js#L49-L51 https://github.com/odoo/odoo/blob/d358542c9159f325b4e2ff184ed1f5cdb6b8c5a9/addons/website_sale_stock/static/src/js/variant_mixin.js#L83-L86 While the `free_qty` is correctly computed from kit products based on the component availability:
https://github.com/odoo/odoo/blob/d358542c9159f325b4e2ff184ed1f5cdb6b8c5a9/addons/mrp/models/product.py#L211-L221 The qties in the virtual cart quantities are not recomputed base on kits.
opw-4889956
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#222945Point of Sale now alerts other devices when an order has been cancelled, paid, or invoiced elsewhere. This prevents staff from continuing to edit an order that is already finalized, avoiding errors during restaurant and checkout workflows.
Original PR description
Before this commit when another device were finalizing an order (cancel, paid or invoiced) the current device was staying on its current screen which can be PaymentScreen, SplitScreen etc. But when the user was trying to edit the order a traceback was raised because the order is finalized. Now when another device is finalizing an order, the current device will be notified and can take appropriate action, such as showing a warning message or preventing further edits to the order. taskId: 4788430
This fixes a restaurant point of sale issue where added items could fail to sync before being sent to the kitchen printer or preparation display. It helps prevent outdated order errors and keeps table orders consistent between the register and server.
Original PR description
Before this commit, if an order had no changes and no preparation display was active, adding items to the order in the restaurant PoS and then returning to the tables would sync the order to the server and mark it as not dirty. As a result, reopening the order and clicking the order button to send it to the preparation display or printer would not sync the updated changes. This caused inconsistencies and errors. Steps to reproduce: 1. Open a table, place an order, and send it to the kitchen printer 2. Add more products but instead of placing the order, go back 3. Re-enter the table, place the order, and send it 4. When placing another order, the error "Order Outdated" appears This commit fixes the syncing logic to ensure that last changes are properly synced, avoiding the "Order Outdated" error. opw-5097566 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The portal timesheet view now shows billed timesheet entries even when a customer opens it from a website linked to another company. This prevents missing timesheet information for users who are allowed to access multiple companies, improving invoice and project transparency.
Original PR description
**Steps to reproduce:** 1. Install hr_timesheet, Sales, Website > add BE company > 2. Go to website, configuration > website > update the website1 company to BE 3. Sales > create new SO > add product Junior Architect (Invoice on Timesheets) 4. Confirm > click to tasks smart-button > add timesheet > back to sales order 5. Create invoice > confirm 6. Preview > View Timesheet **Issue:** View timesheet button shows no timesheet records when accessing from different company website **Cause:** Portal timesheet domain is restricted to current website's company context. When user switches from San Francisco website to Belgium website, timesheets created under San Francisco company become invisible even though user has access to all companies. **Solution:** Add allowed_company_ids context to account.analytic.line model to include all user's accessible companies, allowing cross-company timesheet visibility. **opw-4922212**
Portal payment pages now allow a payment when the customer's linked user has access to the company tied to the document, even if their default company is different. This prevents salespeople in multi-company setups from being blocked when generating payment methods such as Brazilian boleto for the correct company.
Original PR description
Steps ----- 1. Set up a 2nd company with Brazilian l10n; 2. set up Stripe with the boleto payment method; 3. generate a sales order in BRL for BR company; 4. have the salesperson's default company be the 1st company; 5. open sale order preview; 6. attempt to generate a boleto to send to the customer. Issue ----- It wants you to switch to the other company. To do this, you either need change the company on your partner record, or your user's default company (which also changes the partner record). Changing the company in the company selector doesn't work. Cause ----- Portal payments are currently only allowed if the partner has no company, or if the partner's company matches the quotation's company. Solution -------- Also allow payments if the partner has a user profile with access to the document's company. opw-4937531