Wednesday, December 24, 2025
16 changes · saas-18.3
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 resolves a technical issue preventing the correct display of tracebacks when using Peppol for DK Company invoices. The outdated CNAME logic has been removed, aligning with current Peppol standards and ensuring proper functionality. This change improves the user experience for Danish customers.
Original PR description
The function `_check_document_type_support` is extended in `l10n_dk_nemhandel` (from `account_peppol`). The function causes an issue since it contains the old CNAME logic while peppol does not use it anymore; but the newer NAPTR. This commit removes the function - It does not do anything different than the version in `account_peppol` (and it would cause issues if it did) - The function is only called in `account_peppol` - The module does not depend on `account_peppol` Reproduce: - Install `l10n_dk_nemhandel`; check that `account_peppol` is installed - Select `DK Company` - Activate Peppol in test mode - Go to the `DK Company` contact (customers) - Select "By Peppol" and "EU Standard (Peppol Bis 3.0)" - Traceback should appear opw-5232123 Forward-Port-Of: odoo/odoo#241083
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 fixes an issue where the ClickEverywhere function would incorrectly test all applications after a page reload. By storing the application's XML ID, the function now accurately targets and tests only the intended application, ensuring more consistent and reliable test results. This prevents unnecessary testing time and potential errors.
Original PR description
The clickEverywhere function can be executed with one app. To accomplish this, the xmlID should be passed as a parameter to the function. Before this commit, the xmlID of the requested application was not stored in the status of the current execution saved in localStorage. If a reload occurs while the clickEverywhere function is executing, it will lose this information and continue testing all applications instead of only the requested one. runbot.build.error: 234747 Forward-Port-Of: odoo/odoo#240943
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 fixes a technical error that prevented loyalty card codes from being properly applied in the POS system. The issue stemmed from incorrect data being passed, which caused an error. The fix ensures loyalty cards are correctly recognized and applied during transactions.
Original PR description
Steps: ------------ - Install pos_sale_loyalty. - Create a loyalty program of type loyalty, available for both Sales and POS. - Create a sale order with simultaneous customer creation and confirm it. - Open POS and enter code of the loyalty card generated from the sale order. Issue: ------------ - A traceback occurs with: Error: Invalid ids list. Cause: ------------ - A list of partner IDs was passed, where a single partner ID was expected. Fix: ------------ - Extract and pass the correct partner ID instead of the full partner ID list. Task-5388341 Forward-Port-Of: odoo/odoo#239582
This update resolves a technical issue where setting zero quantities in the stock module caused unexpected behavior during quantity calculations. The fix ensures the system correctly handles this scenario, preventing potential errors and maintaining accurate stock levels. This improves the reliability of stock management processes.
Original PR description
The foward port https://github.com/odoo/odoo/pull/239918 did not correctly handle the new `skip_qty_available_update` flag when setting 0.0 quantities, causing some side effects when `_compute_quantities` is run. This commit correctly adds the flag in the needed cases. Forward-Port-Of: odoo/odoo#241000
This update enhances how Odoo retrieves the IP address of IoT Boxes. Previously, it relied on a public DNS server, which failed when the IoT Box was connected to a router without internet access. Now, it uses the gateway's IP address, ensuring functionality even in offline scenarios.
Original PR description
To get the local IP address of the IoT Box, we used to create a connection to a public DNS server and parsed the output to get the source of the request (our IP). In case the IoT Box is connected to a router, but the router isn't connected to the internet, our solution fails. We now create the connection to the gateway instead, so it can work offline. Forward-Port-Of: odoo/odoo#241051
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 corrects a technical issue where unused sign item roles were accumulating in the database, preventing them from being removed. A temporary 'dummy' sign item is now automatically created for each new role, enabling the system to properly clean up these orphaned roles and maintain database efficiency. This ensures a cleaner and more stable sign management process.
Original PR description
Fixes an issue where sign item roles were created but never deleted if they had no sign items linked to them. These orphaned roles were no longer shown in the app and remained in the database indefinitely. To address this, a dummy sign item is now created for each new sign item role. This allows the autovacuum logic to detect and automatically clean up unused roles and dummy items. Without this dummy item, it would be impossible to determine if a role is truly orphaned. task-4971485 Forward-Port-Of: odoo/enterprise#91189
A recent update introduced a bug that caused errors when changing the currency of a journal, specifically when multiple payment methods with different accounts were used. This fix ensures that currency changes are handled correctly, preventing errors and maintaining accurate payment records. The change improves the reliability of our payment processing system.
Original PR description
036530a8983e485ac1ad0b9444a6aba01caabc07 introduced a bug, because it can happen to have 2 (or more) payment method lines from the same payment method. If these PML have differents payment accounts, we get a singleton error. Steps: - On Bank journal, add a new outbound payment method line, which use the same payment method as the first default one (it should be 'Manual') - Set two different payment account for each line - Then change the currency of the journal -> Traceback (singleton error) opw-5384042 Forward-Port-Of: odoo/odoo#239521
This update resolves a recurring test failure in the MRP planning module. The test has been redesigned to manually create the leave, eliminating a specific configuration requirement that triggered the error. This ensures the test consistently runs without failure, improving overall system stability.
Original PR description
Before this commit: Introduced in https://github.com/odoo/odoo/commit/d06dcfbca96273b540c87252b9188603879ac1b4, the test was failing on runbot in some cases. The issue is deterministic, but requires a specific set of modules installed to fail. After this commit: Use a more robust approach in the test, by creating the leave manually instead of computing the number of operations needed. runbot-234638 Forward-Port-Of: odoo/odoo#239717
This 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 corrects a minor issue within the web_studio module, ensuring that report editors accurately reflect the current state of the report. Specifically, a previous code remnant was causing incorrect data retrieval, now resolved to improve report generation reliability. This change enhances the overall user experience for report customization.
Original PR description
Issue: getQwebVariables returns isEditingFooterHeader, but isInHeaderFooter was read from it Cause of the issue: e2eed2b71647de29905bcc1a40c3c540d2a87e47 Forward-Port-Of: odoo/enterprise#102693 Forward-Port-Of: odoo/enterprise#102543
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