Tuesday, September 9, 2025
8 changes · 17.0
Resolved issues and error corrections
Product pages could show a forbidden error to public visitors when extra product information fields were configured but not publicly readable. The change lets the website safely display those configured fields, preventing blocked product pages and improving storefront reliability.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Enable debug mode; 2. go to Website / Configuration / Websites; 3. open first website; 4. open Product Page Extra Fields tab; 5. add Icon (Product); 6. go to a product page as Public User. Issue ----- > **403: Forbidden** > [!Note] > For this issue to occur, the extra field cannot be loaded into cache yet, making it difficult to reproduce in versions before 18.3. As of 18.3, access rights are checked regardless of cache status. Cause ----- It's possible to add extra fields that don't allow access to public users by default. Solution -------- In the `ecom_show_extra_fields` template, retrieve the field values in `sudo` mode. opw-5031708
Checkout now rechecks stock availability when an order is fully paid with a gift card. This prevents customers from completing purchases for products that became unavailable after being added to the cart, keeping online sales aligned with actual inventory.
Original PR description
In this bug, when a order is out of stock, it can be validated if gift card is used as the sole method of payment. This happens when a product gets out of stock while it is on customer's cart. The…
In this bug, when a order is out of stock, it can be validated if gift card is used as the sole method of payment. This happens when a product gets out of stock while it is on customer's cart. The other payment methods fail successfully but if gift card is used, the order can be validated. To reproduce: 1- Create a product and add quantity on stock. 2- Uncheck `Conitnue Selling` in `Out-of-Stock` 3- Publish the product on the website 4- Create a gift card 5- Add the product to the cart using portal user 7- Using admin user, set the quantity to less than ordered quantity 8- Using portal user, proceed to payment, and use the gift card. Then checkout. 9- As you see, the order is validated The issue is because `_check_cart_is_ready_to_be_paid()` which is supposed to check the stock, is only called inside `shop_payment_transaction()`. However, when checking out with gift card, this method is not called. To solve the issue, we can call `_check_cart_is_ready_to_be_paid()` also inside payment validate flow. However this only be called when a gift card is used solely. (The case `order.amount_total` is 0) opw-4941658 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where future time off requests could be calculated using the wrong timezone, especially around daylight saving changes such as in Spain. Employees and HR teams should now see more accurate start and end dates when selecting absences from the calendar.
Original PR description
When selecting an absence for a future date that falls in a different timezone (this can happen in the case of Spain), the default processing of the start and end dates may be using an incorrect timezone.  (The next time change in Spain will occur on Sunday, 26 October 2025) The correct approach would be to base it on the timezone of the start/end dates selected in the calendar.  cc @Tecnativa TT56343 ping @sergio-teruel @victoralmau --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210068
Saved-card payments in website checkout are now held until the order has passed final validation. This prevents customers from being charged when a last-minute issue, such as an expired coupon, blocks the order from completing.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Have a saved Stripe payment token; 2. create a discount coupon program & a coupon; 3. go to /shop & add a product to your cart; 4. go to checkout; 5. apply coupon; 6. before finalizing payment, set coupon program expiration to yesterday; 7. finalize payment. Issue ----- An error appears, because of the reward change, but a payment request has already been sent. Cause ----- For token transactions, `_send_payment_request` is called immediately upon creation, i.e. before the `WebsiteSale` controller is able to validate the transaction using `_validate_transaction_for_order`. Solution -------- If the payment flow happens via token, add a `delay_payment_request` context value. When creating a token transaction in `PaymentPortal`, only call `_send_payment_request` if this value is not set in the current context. opw-5013284
This fix stops work orders from accidentally changing their product when users drag and drop them in the Manufacturing Planning view. It helps keep production plans accurate and prevents unintended changes caused by grouping or moving work orders visually.
Original PR description
Issue ----- In the Planning view, grouped by Work Center > Product, dragging & dropping can change the product of the WO if the user is not careful and drops the WO on top of another product's WO.…
Issue ----- In the Planning view, grouped by Work Center > Product, dragging & dropping can change the product of the WO if the user is not careful and drops the WO on top of another product's WO. Steps to reproduce ----- - Have 2 products - Create a MO for product 1 with a WO at work center 1, plan it - Create a MO for product 2 with a WO at work center 2, plan it - Got to Manufacturing, Planning, Planning by Work Center - Add a custom group (by product) - Drag the WO of WC2 and drop it on top of the other WO > Both the WC and the product of the second WO change Cause ----- The problem is only for versions 17.0 & 18.0 where the `product_id` field of `mrp.workorder` is defined as such https://github.com/odoo/odoo/blob/31e46a841b38de0f99beb1844f985bc670621486/addons/mrp/models/mrp_workorder.py#L34 While the user cannot change the field value manually, automatic actions such as a gantt view drag & drop can change its' value by using `write` since it is stored. Starting in 18.2, the field is no longer stored so trying to write a value for it doesn't work anymore. https://github.com/odoo/odoo/blob/f337573ffc2642524b50608e2990270c69e8e547/addons/mrp/models/mrp_workorder.py#L39 ----- Ticket: opw-4875366
Paying a sale order in Point of Sale now handles products split across multiple lots correctly. This prevents overstated stock movements and avoids removing the full ordered quantity from each lot by mistake.
Original PR description
Backport of [687e2c8](https://github.com/odoo/odoo/commit/687e2c848138e62c8b4df95044e4e88e20803657) Issue: ------ When settling a SO in PoS, the full quantity is removed from every lot. Steps to reproduce: ------------------- * Create a product tracked by lot * Create 2 lots for that product * Lot 1 with 2 of the product * Lot 2 with 3 of the product * Create a sale order for 3 of that product * Confirm the sale order * Pay the order in the POS * Check the picking created for the pos order > Observation: The picking created for the pos order has double the quantity, with each lot getting 3 units picked from. Why the fix: ------------ A PoS line can only hold one lot, so when we import a sale order with multiple lots, we need to split the line into multiple lines, each with a single lot. opw-4977785
This fix makes the live chat chatbot resume from the correct step when a visitor returns to an existing conversation. It prevents unexpected restarts caused by reordering chatbot steps, improving continuity for website visitors and support teams.
Original PR description
before this commit, `isRestoringSavedState` was computed by comparing chatbotStep IDs instead of the sequence number. This is an unreliable method that could lead to unexpected restart of the chatbot flow if the user created their steps in a certain order then swapped that order around. Besides, the field `sequence` is precisely meant to track this state. This commit adds `sequence` and computes the `isRestoringSavedState` based on that sequence. opw-4858896
This fix ensures Odoo Studio shows only valid measure fields when configuring a cohort view, preventing users from selecting incompatible options that caused errors. It also removes an unnecessary request parameter to avoid warning messages when creating new views.
Original PR description
Currently, an error occurs when user tries to select any measure in cohort view. Steps to replicate: - Install `sale_management` and `web_studio`. - Open the Sales app and turn on studio mode. -…
Currently, an error occurs when user tries to select any measure in cohort view. Steps to replicate: - Install `sale_management` and `web_studio`. - Open the Sales app and turn on studio mode. - Under the Views tab, turn on cohort view. - Under the Measures field, select any value and observe the error appearing in the terminal. Error: `ValueError: Invalid aggregate method 'None' for 'create_date:None'` Cause: - The Measure field dropdown in the Cohort Editor was mistakenly assigned the choices of `dateFields` [1] instead of `measureFields`. - This allowed users to select incompatible field types (e.g., date/datetime), which lead to error in aggregation behavior in the cohort view. Solution: - Corrected the choices of Measure field to `measureFields`. - Also added a condition to allow only those fields that have an aggregator (for some fields like `sequence` that dont have an aggregator). - Also removed context field from arguments [2] in the rpc call as function doesnt need it [3] (This shows warning on runbot as well). [1]: https://github.com/odoo/enterprise/blob/d8539dff5f3dcecfeb99fd7fc22a6915aaa02c4b/web_studio/static/src/client_action/view_editor/editors/cohort/cohort_editor_sidebar.xml#L30 [2]: https://github.com/odoo/enterprise/blob/bf9510e152279418200cb0becb6b637c19b02d4e/web_studio/static/src/client_action/editor/new_view_dialogs/new_view_dialog.js#L87 [3]: https://github.com/odoo/enterprise/blob/bf9510e152279418200cb0becb6b637c19b02d4e/web_studio/controllers/main.py#L805 sentry-6781792463