Wednesday, November 19, 2025
7 changes · saas-18.2
Resolved issues and error corrections
Fixes an issue where quickly removing a product right after adding it from the sales catalog could trigger an error and interrupt order editing. The system now falls back to the product price from the order pricelist when no sales order line has been created yet, keeping the workflow smooth for users.
Original PR description
Currently, an error occurs when the user immediately removes a catalog product after adding it. Steps to Reproduce ([Video](https://drive.google.com/file/d/12hOavt1zCa6hbG0EWHsIDGxfgVkxJmLW/view)): -…
Currently, an error occurs when the user immediately removes a catalog product after adding it. Steps to Reproduce ([Video](https://drive.google.com/file/d/12hOavt1zCa6hbG0EWHsIDGxfgVkxJmLW/view)): - Install the `sale_management` module. - Go to `Sales Orders` and create a new `sale order`. - In the order line, click on the `Catalog` button. - `Add` a product and then immediately `remove` it. `ValueError: Expected singleton: sale.order.line()` After [this commit], when the user clicks the Remove button immediately after clicking the Add button (within 500 ms). In this case, the system proceeds with the last request due to the useDebounced delay [1], which removes the product. However, since there is no order line yet for that product [2] and the quantity is 0, the order line [3] is not created. When it attempts to retrieve the discounted price, it raises the error [4]. This commit ensures that if no order line exists, the product's price is returned according to the sale order's pricelist. [this commit]: https://github.com/odoo/odoo/pull/233098/commits/697c559791fdf00b5602b9459bbdf21f392757d8 [1]- https://github.com/odoo/odoo/blob/ec212f38e50520edf612522717952855c8c09a80/addons/product/static/src/product_catalog/kanban_record.js#L17-L19 [2]- https://github.com/odoo/odoo/blob/ec212f38e50520edf612522717952855c8c09a80/addons/sale/models/sale_order.py#L2202 [3]- https://github.com/odoo/odoo/blob/ec212f38e50520edf612522717952855c8c09a80/addons/sale/models/sale_order.py#L2218-L2219 [4]- https://github.com/odoo/odoo/blob/ec212f38e50520edf612522717952855c8c09a80/addons/sale/models/sale_order_line.py#L1602-L1603 sentry-7019831319 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235470
The import panel now recognizes CSV files regardless of whether the file extension uses uppercase or lowercase letters. This ensures users see the same formatting options for files such as .csv and .CSV, reducing confusion during imports.
Original PR description
Before this fix, the import side panel displayed the formatting options only when the uploaded file had a lowercase .csv extension. Files with an uppercase .CSV extension could still be imported but did not show the format selection section, leading to inconsistent behavior. This commit updates the condition to perform a case-insensitive comparison on the file extension. Task-5145031 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236020 Forward-Port-Of: odoo/odoo#235061
This fix ensures accounting users see the complete list of unbalanced journal entries when an error occurs, instead of only the first one. It makes troubleshooting faster and reduces confusion when several entries need correction.
Original PR description
The commit 3467b5971423f70581c6be2caf7f8a8d86ee70f1 intended to improve the error message in `_check_balanced()` by tailoring it based on the number of affected entries. However, in the case of multiple affected entries, the error was raised after the first iteration, preventing the full list of unbalanced entries from being collected and displayed to the user. no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236212
Calendar event markers now remain visible when events use a hatched style, such as unpublished planning entries. This makes status indicators easier to read and ensures the same display behavior even when the Calendar app is not installed.
Original PR description
When pills are hatched (unpublished event) in the calendar view (eg. planning) the `o_event_dot` is barely visible. Additionally the styling to display the dot as outlined on hatched event is wrongly scoped in `/calendar` with the calendar status styling. It should be in the view instead. Otherwise, for the planning module which doesn't depend on calendar, the styling is not applied if calendar is not installed, rendering the filled dot. task-3916768 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235978 Forward-Port-Of: odoo/odoo#235286
The replenishment list now correctly filters items when users search for a To Order quantity of zero. This prevents products that still need ordering from appearing in zero-quantity results, making inventory planning more accurate.
Original PR description
**Issue** In replenishment, filtering with `to_order = 0` does not correctly exclude records where `to_order != 0`. **Steps to reproduce** 1. Go to Inventory > Operations > Procurement >…
**Issue** In replenishment, filtering with `to_order = 0` does not correctly exclude records where `to_order != 0`. **Steps to reproduce** 1. Go to Inventory > Operations > Procurement > Replenishment 2. Create a replenishment with a forecast quantity smaller than the min and max quantity (without editing the To Order) 3. Apply a custom filter `to_order = 0` → Records with non-zero `to_order` are incorrectly included **Cause** `qty_to_order` was split into `qty_to_order_computed` and `qty_to_order_manual` in [this commit](https://github.com/odoo/odoo/commit/156bed3f430d706e13822bbd95d91c8dfd3ea42d#diff-0eb18a8d7773b5f99b402392188594178c3ba2004e4bcab26dbc84b1c8d7256a). In the [`_search_qty_to_order` method](https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/stock/models/stock_orderpoint.py#L338), all records with `qty_to_order_manual = 0` are included. Since `qty_to_order_manual` defaults to 0 when untouched by the user, this causes incorrect results. Additionally, [`to_order`](https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/stock/models/stock_orderpoint.py#L323) displays `qty_to_order_computed` if `qty_to_order_manual = 0`, creating inconsistency. **Solution** Fix the inconsistency by ignoring `qty_to_order_manual` when searching for zero `to_order` values. opw-5150643 Forward-Port-Of: odoo/odoo#234908
This fix places portal rating message handling in the module that actually supports portal features. It helps avoid dependency mismatches and keeps rating-related portal behavior working reliably in the right context.
Original PR description
Since #234356, `_get_allowed_message_post_params` method of the `PortalChatter` has been overridden in the `rating` module. As the `rating` has no dependency on the portal, the current change moves this override to the `portal_rating` module. Forward-Port-Of: odoo/odoo#236249
This update fixes an internal automated test so it more accurately reflects how users change event-related products in the interface. It helps ensure Odoo continues to block invalid event ticket product settings consistently during quality checks.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have a minimal database with `event_product` installed; 2. run `:TestEventProduct.test_ensure_event_service_tracking`. Issue ----- > FAIL:…
Versions -------- - 18.0+ Steps ----- 1. Have a minimal database with `event_product` installed; 2. run `:TestEventProduct.test_ensure_event_service_tracking`. Issue ----- > FAIL: TestEventProduct.test_ensure_event_service_tracking > AssertionError: ValidationError not raised Cause ----- The test works as expected with `sale_project` installed due to a `write` override of `product.product`, setting the `service_tracking` to 'no' if `type` is no longer 'service': https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/sale_project/models/product_product.py#L25-L30 This change still occurs without `sale_project` installed, but via the `_compute_service_tracking` method defined in `product`: https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/product/models/product_template.py#L181-L183 As this value is set via a compute method instead of `write`, the `_check_event_ticket_service_tracking` method isn't triggered, and no error is raised. Solution -------- Simulate a front-end flow by changing the `type` to 'consu' on a product form. This way, the constraint method does get triggered as expected. runbot-234024 Forward-Port-Of: odoo/odoo#236045