Wednesday, November 19, 2025
4 changes · saas-18.3
Resolved issues and error corrections
When a product was edited and saved in Point of Sale, its reference could briefly appear before the product name. This fix keeps the display consistent so staff see the expected product name instead of the reference code.
Original PR description
In PoS, when editing and saving a product’s information, there was a bug where the product reference was shown before its name. Steps to reproduce: ------------------- * Add a reference to a product available in PoS * Open PoS * Click on the 'i' on the top right of that product * Click on Edit * Click on Save (no need to do any modification) > Observation: The reference appears before the name. Refreshing the page removes, as it triggers a new read. Why the fix: ------------ Reference are never shown in pos thank to this context key `display_default_code: false` opw-5001355 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233812 Forward-Port-Of: odoo/odoo#222640
The import screen now correctly shows formatting options for CSV files even when the file name ends with .CSV in uppercase. This makes the import experience more consistent and avoids confusion for users importing data from different sources.
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 change makes event markers easier to see when an event is displayed with a hatched style, such as unpublished items. It also moves the styling to the correct place so the display stays consistent even when the calendar app is not installed, which helps modules like Planning show the right appearance.
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
This update corrects an automated test so it matches how users actually change a product in the interface. As a result, the test now properly detects invalid event-related product settings and prevents false passes in simpler installations.
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