Wednesday, December 24, 2025
8 changes · saas-18.3
Enhancements to existing features
This update enhances the testing process for the POS Restaurant module's preparation display functionality. By adding Hoot tests and a dedicated test environment, the team is ensuring greater reliability and accuracy of this key feature, reducing potential issues before they impact users.
Original PR description
In this commit: --- - Added HOOT test coverage for the POS Restaurant module's preparation display. - Introduced `setupPosPrepDisplayEnv` to mock and initialize the preparation display test environment. - Added test coverage for core components, models, and service logic. - Adjust hoot case for pos_urban_piper. task-5225193 Related PR: - https://github.com/odoo/odoo/pull/234474
Resolved issues and error corrections
This update fixes an issue where the 'late' filter on deliveries was incorrectly returning all outgoing pickings, regardless of their status. The change adds a necessary separator between filters, ensuring that users only see deliveries that are genuinely marked as 'late'.
Original PR description
Issue: ------------------------------------------ When opening deliveries and applying the 'late' filter, the results show: - All `outgoing pickings`, regardless of whether they are `late` or not,…
Issue: ------------------------------------------ When opening deliveries and applying the 'late' filter, the results show: - All `outgoing pickings`, regardless of whether they are `late` or not, and - All `late pickings`, regardless of their `picking type`. In short: `Deliveries OR Late`. The same issue occurs with other picking types as well. How to reproduce: ------------------------------------------ 1. Install stock. 2. Open deliveries through operations menu. 3. Apply 'late' filter. Cause of the issue: ------------------------------------------ There is no `seperator` between `picking_type_code` and `date_category` filters, so OR operator is applied between them. Solution: ------------------------------------------ Added `seperator` between `picking_type_code` and `date_category`. which now shows only the outgoing pickings which are late. In short: `Deliveries AND Late`. This helps users to apply filters like: Find deliveries that are late. Task ID: [4614363](https://www.odoo.com/odoo/project/966/tasks/4614363) Forward-Port-Of: odoo/odoo#201344
This update fixes an issue in the Hungarian localization where e-invoices incorrectly used the invoice date to determine currency exchange rates. Now, the system accurately uses the delivery date, as required for Hungarian e-invoice regulations. This ensures compliance and accurate financial reporting for transactions in the Hungarian market.
Original PR description
In the Hungarian localization, the currency exchange rate for invoices is based on the delivery date. Steps to reproduce: - With HU localization setup - Create an invoice Issue: Currently, when issuing the e-invoice, the system would compute the currency exchange rate using the invoice date. opw-5126816 Forward-Port-Of: odoo/odoo#240999
This update resolves an issue where deleting a Point of Sale order didn't properly remove associated order lines from local records. The fix corrects a technical problem related to how data was accessed, ensuring that all related items are now removed during order deletion. This improves data accuracy and prevents orphaned records.
Original PR description
Issue: Deleting an order did not remove its related order lines from local records. Cause: Because of the use of `lazyGetter`, model fields were defined as getters instead of object keys. This caused `Object.entries` to skip some fields, preventing cascade deletion from including child records. Fix: Updated the logic for computing `recordsToDelete` to correctly handle cascade deletion and ensure child records are properly removed. Task-5095578
This update streamlines the planning process by automatically notifying users when employee work emails are missing. Instead of a blocked wizard, users receive a list of employees needing email information, allowing for quick action like removal or requesting completion from HR. This improves efficiency and prevents delays in sending plans.
Original PR description
Before this commit, when the planning manager wants to send the planning and for some employees the work email is missing, the user is blocked on the wizard to fill the work email on those employees if he does not edit access to employee model. This commit makes sure the wizard to fill in the missing work email is not displayed if the user cannot edit the information of the employees. It also displays a notification listing the employees for which the work email is missing. By doing that, the user can easily remove those employees to continue his flow or ask to HR user or the employees concerned to complete the missing information. task-5090163 Forward-Port-Of: odoo/enterprise#102458 Forward-Port-Of: odoo/enterprise#96111
This update resolves an issue where refunding and canceling orders in Point of Sale (POS) would sometimes lead to a blank screen and errors. The fix ensures that related order data is properly removed when a refund or order cancellation is performed, improving the stability and reliability of the POS system.
Original PR description
Step to reproduce: (try this in 19.0) - open pos and settle a order - refund the same order, from payment screen, go back to product screen - cancel this order - again try to refund the same order…
Step to reproduce: (try this in 19.0)
- open pos and settle a order
- refund the same order, from payment screen, go back to product screen
- cancel this order
- again try to refund the same order
Observation:
- Blank screen with traceback in console
```
Caused by: TypeError: Cannot read properties of undefined (reading 'state')
at Proxy.reduce (<anonymous>)
at get refundedQty
```
Cause:
- refundedQty() reads refund_orderline_ids.order_id.
- On the first refund cancellation, the refund was deleted but its related order_line was not.
- Order deletion relies on localDeleteCascade, which uses Object.entries() to find related records to delete.
- With lazy getters, this fails because Object.entries() does not expose or execute getter-based properties.
Fix:
- as we already have keys `relationsToDelete`, we pull the value, which execute the getter and we will have the needed data.
- Fixed the test, as for new order, we expect the newer orderline, older ones
should be deleted.
opw-5379747
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves an issue where overlays disappear after refreshing the website editor in version 18.4 and later. The fix focuses on cleaning up the HTML editor's elements to prevent the removal of newly created overlays. This ensures overlays are consistently visible during editor operations.
Original PR description
The bug is only observable after 18.4, after the website refactoring, but the root cause has been present since 18.0, so we fix it there in case there are other use cases. Since [1], overlays are no longer visible after an operation that executes `reloadEditor`. Steps to reproduce (observable after 18.4): - On website, go into edit mode - Change header template - After reload, overlays are missing Reason: `WebsiteBuilderClientAction.reloadEditor` sets up the new `Editor` before the old one is destroyed. Consequently, `LocalOverlayPlugin.destroy` removes the newest overlays as well. This commit ensures the plugin only cleans up its specific DOM elements. The order of operations bug will be fixed in a later PR. task-5438306 [1]: https://github.com/odoo/odoo/commit/3cd29fbac2b06566bfff40b5e7ed310cb0ce12c1 Forward-Port-Of: odoo/odoo#241161
This update significantly speeds up the generation of budget reports by optimizing how data is filtered. Previously, a slow process required generating a large, unfiltered table, leading to delays. Now, the filtering is applied directly within the underlying queries, dramatically reducing processing time and improving report performance.
Original PR description
Previously, generating the budget.report table was necessary to trigger _compute_all for budget.line fields. This table was built using three separate queries with a UNION operator. Because of the…
Previously, generating the budget.report table was necessary to trigger _compute_all for budget.line fields. This table was built using three separate queries with a UNION operator. Because of the UNION, any filtering (like on specific budget_line_ids) happened after the full, unfiltered table was generated. This post-filtering caused slowness, especially in nested loop joins with large tables like account.analytic.line. This commit optimizes performance by pushing the filter condition (using specific budget_line_ids) directly down into the three underlying queries. This reduces the number of budget.line records processed, speeding up joins and overall computation. The benchmark below is done on a database that has **66396** `budget.line` records and **928567** `account.analytic.line` records. Opening a budget report for a specific year, only applied the filter with **40** `budget.line` records. | Scenario | Execution Time | | :--- | :--- | | **Before this Commit** | **60.00 seconds** | **After this Commit** | **1.84 seconds** opw-5150569 Forward-Port-Of: odoo/enterprise#102771 Forward-Port-Of: odoo/enterprise#99096