Wednesday, December 24, 2025
17 changes · saas-18.4
Resolved issues and error corrections
This update resolves a bug where the 'convert to task' option repeatedly appeared for converted Todo items. The fix hides this option when a project is assigned, streamlining the process and preventing unnecessary conversions. This improves user experience and data consistency.
Original PR description
Steps to reproduce: - Create a Todo and convert into task using cog Menu option. - Todo is converted to task and is displayed. - Through breadcrumb go back to Todo - Try to convert it again Issue: - The converted todo is again converted (change of project etc) Fix: - Hiding the convert cog menu when a project is set. task-5075327 Forward-Port-Of: odoo/odoo#240821 Forward-Port-Of: odoo/odoo#230031
This update fixes an issue where the 'late' filter on deliveries was incorrectly showing all outgoing pickings, regardless of their status. The change adds a necessary separator between filters, ensuring that users only see deliveries 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 a minor inconvenience for users. Previously, clicking 'Jump to Present' would cause the composer to lose focus, requiring manual adjustment. Now, the composer automatically regains focus on desktop after this action, improving the user experience.
Original PR description
**Current behavior before PR:** clicking "Jump to Present" caused the composer to lose focus, forcing users to manually focus the input before typing. **Desired behavior after PR is merged:** The composer automatically regains focus on desktop after clicking "Jump to Present". task-[5035977](https://www.odoo.com/odoo/project/1519/tasks/5035977) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240994 Forward-Port-Of: odoo/odoo#227781
This update ensures that product images are hidden in the combo product configurator, aligning with the overall POS settings for product image visibility. Previously, combo products displayed images regardless of the configured settings, creating a confusing user experience. This change improves consistency and simplifies the product selection process for customers.
Original PR description
Before this commit: ==================== In POS, when product images were configured to be hidden, the setting was correctly applied to normal products. However, in the combo product configurator, product images were still displayed, causing inconsistency with the configured behavior. After this commit: ====================== The combo product configurator now respects the product image visibility configuration, ensuring consistent behavior across all product types in the POS interface. Task-5163955 Forward-Port-Of: odoo/odoo#240997 Forward-Port-Of: odoo/odoo#231366
This update resolves a technical issue causing a traceback when using Peppol integration for Danish companies. The outdated CNAME logic has been removed, aligning with current Peppol standards (NAPTR). This ensures proper Peppol functionality and a smoother user experience.
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 calculate currency exchange rates. The fix ensures the currency rate is based on the invoice delivery date, aligning with Hungarian tax regulations. This ensures accurate e-invoice generation and compliance.
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 specific application's XML ID, the function now accurately targets the intended application, ensuring consistent and reliable test execution. This prevents unnecessary testing and improves the overall stability of the testing process.
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 fixes a minor inconsistency in the documentation for our phone number handling features. The previous documentation incorrectly referenced a method that was never actually used. This change ensures the documentation accurately reflects the current codebase, improving clarity for developers.
Original PR description
A mention to `_voip_get_phone_field` appeared in [1] but this seems to never have existed. In any case, `_phone_get_number_fields` was used by the codebase in the end and should thus be the one mentioned. [1]: https://github.com/odoo/enterprise/commit/52b3065993c41c6b7c65dda586a66fdd865b3afd Forward-Port-Of: odoo/enterprise#102804
This update streamlines the planning process by automatically notifying managers when employee work emails are missing. Instead of being blocked by a manual wizard, users receive a list of employees needing email information, allowing for quick action like removal or escalation to 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 enhances the way Odoo retrieves the IP address of IoT devices. Previously, it relied on a public DNS server, which failed when the device was connected to a router without internet access. Now, it connects to the gateway, 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 fixes an issue where deferred accounting for misc entries wasn't correctly identifying the appropriate account type. The change now analyzes each deferred line individually, ensuring deferrals are linked to the correct expense or revenue account, enhancing financial accuracy. This improves the handling of complex transactions.
Original PR description
The commit 42f823d6b8aa3d1cd171ae1603549ee95fc9d0f0 allows to use deferred on misc entries. However, there are many places in the code that were not updated. Usually they were in the form of `if move_type is sale, then deferred_type = income, else expense`. However we cannot rely on the move_type anymore for misc entries, because it will always take the `else` branch of the condition. Instead, if we have a misc entry, we should rely on the account type of the line that is being deferred, so we have more granularity. For this, we now compute the deferral account/journal for each line, and not per move. The logic inside the computation remains the same. Steps to reproduce: 1. Create a misc entry with two deferred lines (one expense, one revenue) 2. Post it 3. Check the generated deferrals, they all use the same deferred account and journal even though we have different account types opw-5194305 Forward-Port-Of: odoo/enterprise#100295
This update fixes a critical bug that caused Odoo to crash when sending invoices via Peppol with invoice lines lacking a product name. Now, the system gracefully displays an error message, guiding users to ensure each invoice line has a product or label before sending. This improves invoice processing reliability and prevents data loss.
Original PR description
Before this commit: When sending an invoice via Peppol with an invoice line that has no product name, the system crashes with a TypeError instead of showing a error message. Steps to reproduce: 1. Go to Accounting 2. Navigate to Customers > Invoices 3. Create a new invoice 4. Add an invoice line without entering a product name 5. Click 'Send' 6. Select 'by Peppol (Demo)' 7. Click 'Send' -> TypeError: 'NoneType' object is not subscriptable After this commit: System validates that the product name exists before accessing its text content. Users see a clear, error message: `Each invoice line should have a product or a label.` task-5432061 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240908
This update resolves a technical error that prevented loyalty cards from being correctly applied during POS transactions. The issue stemmed from incorrect data being passed to the system, specifically a list of customer IDs instead of a single ID. This fix ensures loyalty card codes function as expected, improving the customer experience.
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#241167 Forward-Port-Of: odoo/odoo#239582
This update resolves a bug that occurred when changing the currency of a journal, specifically when multiple payment method lines used different payment accounts. This prevented accurate recording of payments and could lead to inconsistencies. The fix ensures correct currency handling during journal changes.
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 fixes an issue where deleting a Point of Sale order didn't properly remove associated order items from local records. The fix addresses a technical problem related to how data was accessed, ensuring that all related records 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 Forward-Port-Of: odoo/odoo#227875
This update resolves an issue where overlays disappear after refreshing the website editor in version 18.4 and later. The problem stemmed from how the editor is reloaded, causing a cleanup of overlays. This fix ensures overlays are correctly displayed after editor refreshes, improving the user experience when making website changes.
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 table, but now the filtering is applied directly within the underlying queries, reducing processing time and improving report loading speed. This results in a much quicker user experience.
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