Monday, March 16, 2026
8 changes · saas-18.4
Resolved issues and error corrections
Fixes an issue where upload actions inside the three-dots menu on small screens could close too quickly and fail. This ensures users can upload documents such as vendor bills from mobile or narrow browser views without changing screen size.
Original PR description
## Issue: On small screens, when an upload widget is placed inside a dropdown (e.g., Upload Bill from a Purchase Order), the action does not work Clicking the dropdown item closes the dropdown immediately, which prevents the widget action from completing ## Cause: Widget actions require an accessible anchor element to function properly. However, dropdown items automatically close the dropdown on click As a result, the widget is triggered but immediately detached from the DOM before its action can fully execute ## Steps to reproduce: - Install `purchase_stock` (to have the Upload Bill widget available) - Create and confirm a Purchase Order (the Receive button must be available) - Reduce the browser width until the action buttons collapse into the three-dots menu - Click Upload Bill and try to upload a document opw-5918379 Forward-Port-Of: odoo/odoo#251492
Refunds paid through a customer-identified card payment method are now recorded as outgoing payments instead of incoming ones. This keeps POS refund records accurate in invoicing and prevents duplicate-looking customer payment entries with the wrong payment direction.
Original PR description
Step to reproduce: - Install point_of_sale - Enable Identify Customer on the Card payment method - Create an order with a customer and refund it - Use Card as the payment method - Close the POS…
Step to reproduce: - Install point_of_sale - Enable Identify Customer on the Card payment method - Create an order with a customer and refund it - Use Card as the payment method - Close the POS session - Go to Invoicing → Customers → Payments Observation: - Two payment records are created - Both payments have payment_type = inbound - The refund payment should be outbound Cause: - When Identify Customer is enabled, `_create_split_account_payment` is used to create payment records - The method does not adjust payment_type for refund transactions Fix: - Add helpers to swap destination and outstanding accounts - Set `force_outstanding_account_id` instead of `outstanding_account_id`, as the former has priority - Ensure refund payments are created as `outbound` few related fix: https://github.com/odoo/odoo/commit/303a9061da85048f14a3ca7b1e13df0ab34da99e https://github.com/odoo/odoo/commit/718fac6832ecd343bf26d41fa5ae5b1ab74f4228 https://github.com/odoo/odoo/commit/684415b9ff2e151506da561016dbfa991bfa8dc8 opw-5437456 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252875 Forward-Port-Of: odoo/odoo#247760
Point of Sale now correctly records change given back to customers when an invoiced order is overpaid by card or bank payment and no cash payment method was used. This prevents customer balances from incorrectly showing that the business still owes money after the register is closed.
Original PR description
If an order in overpaid using bank, no move line is created for the change. Steps to reproduce: ------------------- * Make an order, add a customer * During payment, select invoice, pay more than the…
If an order in overpaid using bank, no move line is created for the change. Steps to reproduce: ------------------- * Make an order, add a customer * During payment, select invoice, pay more than the order amount with bank pm * Validate * Close register * Check customer > Observation: It says we owe the customer money, although change was given. Why the fix: ------------ Since this fix: https://github.com/odoo/odoo/commit/2c4764f111eec154375d94eb7052a12c470a513d the change gets deducted from cash payment method. However the use case where there would not be any cash payment used was not taken into account. The previous fix was removing the change from the payment methods to subtract its amount from any cash payment but in the case where there's none nothing is done with it. Indeed it sometimes happen to pay a bit more in card to get some cash out. Currently, in this case, the change is just omitted. opw-5149700 Forward-Port-Of: odoo/odoo#253311 Forward-Port-Of: odoo/odoo#247621
This fix ensures dropshipped backorders are valued using the actual delivered quantity when a vendor bill already exists. It prevents inventory valuation entries from being overstated, improving accounting accuracy for FIFO and average-cost products.
Original PR description
…order dropship **Problem:** when the backorder of the delivery (with a bill) of a dropshipped fifo/avco product is validated, the svl created don't have the right values **Steps to reproduce:** -…
…order dropship **Problem:** when the backorder of the delivery (with a bill) of a dropshipped fifo/avco product is validated, the svl created don't have the right values **Steps to reproduce:** - create a new product, with dropship and buy routes - in the purchase tab select "on ordered quantities" - add a vendor with a price of 10 - create a new quotation for a quantity of 10 - confirm and confirm the purchase order - click on "create bill" and confirm it - go back to the PO and click on the "dropship" smart button - change the quantity to 5, validate and create backorder - go back to the PO, click on the "dropship" smart button and select the picking of the backorder (with status ready) - validate - click on the "valuation smart" button **Current behavior:** the svl created for the backorder have a value of 100 and -100 **Expected behavior:** it should be 50 and -50 **Cause of the issue:** inside _get_dropshipped_svl_vals _get_price_unit is called https://github.com/odoo/odoo/blob/f7c8cc76f15bc6e974969fb4ab4a93654443b973/addons/stock_account/models/stock_move.py#L219 because we created a bill and it's a backorder line.qty_invoiced is higher than received_qty and this condition is true https://github.com/odoo/odoo/blob/f7c8cc76f15bc6e974969fb4ab4a93654443b973/addons/purchase_stock/models/stock_move.py#L51 but because it's a dropship there is as much positive svl as negative svl linked to the move so receipt value is null https://github.com/odoo/odoo/blob/f7c8cc76f15bc6e974969fb4ab4a93654443b973/addons/purchase_stock/models/stock_move.py#L56-L63 and remaining value will be 100 instead of 50 (receipt value should have been 50) https://github.com/odoo/odoo/blob/f7c8cc76f15bc6e974969fb4ab4a93654443b973/addons/purchase_stock/models/stock_move.py#L80 **fix** the negative svl from the dropshipped move should not impact receipt value opw-4888827 Forward-Port-Of: odoo/odoo#224490 Forward-Port-Of: odoo/odoo#216899
The online shop product search now submits correctly when visitors use the mobile view. This helps shoppers find products from mobile product pages instead of the search appearing to do nothing.
Original PR description
Steps to produce: --- - Install `website_sale` module. - Go to `website > shop`. - Open the `Customizable Desk` product page. - From the website editor, `enable the search bar` for the product page. - Switch to `mobile view`. - Now search for `drawer` in product search. Issue: --- - In mobile view, the search does not work. When performing a search, nothing happens, and the request is not executed. Root cause: --- - At [1], in the search template definition, the action attribute is missing in the search form. Solution: --- - Set the form action using keep(search=0) instead of leaving it undefined. - This ensures that the search behaves correctly depending on the context (global or category-scoped). [1]https://github.com/odoo/odoo/blob/51f59a293de1e86f66f30257f8fc0c419463d18c/addons/website_sale/views/templates.xml#L2239-L2259 opw-5992052 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Manufacturing unbuild orders now handle cases where users unbuild more items than were originally produced without creating stuck stock movements. This prevents blocked inventory records and keeps warehouse operations moving when correcting or reversing manufacturing orders.
Original PR description
# How to reproduce - Create a BOM for a product - Create a MO for a set quantity (Exemple: 1) for that product - Unbuild that MO and ask to unbuild more than what was manufactured (Exemple: 3) -…
# How to reproduce - Create a BOM for a product - Create a MO for a set quantity (Exemple: 1) for that product - Unbuild that MO and ask to unbuild more than what was manufactured (Exemple: 3) - Confirm the unbuild - Go to the stock moves of that unbuild via the smart button # The problem 3 stock move lines are created, 2 in the 'Done' state and 1 in the 'Available' state. This last move line is stuck and cannot be validated # Why The cause of this issue is due to a discrepency between the quantity set for the move lines and the quantity set for their respective moves. When creating the move lines for the produce move, we use the original move of the MO (this is done to keep Lots consistent). If the quantity of product to unbuild is more than the quantity of product built by the MO, the quantity of the move lines will be less than expected. This will then create a backorder when the produce move is set to done. This backorder will then be unvalidatable because the unbuild it is linked to will be set to 'Done'. opw-5915981 opw-5449109 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248056
This fix ensures each image gallery added to a website page receives a truly unique identifier, even after saving and reopening the editor. This prevents navigation controls on a newly added gallery from accidentally controlling an older gallery, improving reliability for website editors.
Original PR description
Commit [86a3f41] called `uniqueId()` to generate the image gallery id in the builder options. However, `uniqueId()` is only unique in the course of the current client session. As a result, you could drop a gallery, save your page, refresh it, edit the page and drop another gallery with the same id as the 1st one. Steps to reproduce: - Drop an image gallery - Save - Refresh - Go back to edit - Drop another image gallery => Check their ids. It's very probable that they are the same. - Save - Click on the "Previous" or "Next" arrow of the 2nd gallery => it updates the 1st carousel, not the 2nd one. [86a3f41]: https://github.com/odoo/odoo/commit/86a3f41a71a91c656a9969a4ef251f8c2ce3a266
This update resolves an issue where rental income was incorrectly included in the Total Income batch calculation for Hong Kong payroll. The fix removes any rental amounts during this calculation, ensuring accurate reporting of employee income as required by Hong Kong tax regulations. This improves the reliability of payroll data.
Original PR description
. Removing any rental amounts in calculating Total Income batch task-6006636 Forward-Port-Of: odoo/enterprise#109919