Friday, April 10, 2026
9 changes · 19.0
Enhancements to existing features
This update streamlines the way odoo.com accesses database information, eliminating an outdated XMLRPC fallback. This change improves performance and simplifies the system, ensuring faster KPI synchronization for the odoo.com platform. Additionally, a new route is implemented to group database calls, mirroring the efficiency of the existing mail activity summary dashboard.
Original PR description
### [IMP] databases: remove xmlrpc fallback for odoo.com Since odoo.com migrated to 19.0, it will always support the json2 API, and XMLRPC support will be dropped on the next version. In order to…
### [IMP] databases: remove xmlrpc fallback for odoo.com Since odoo.com migrated to 19.0, it will always support the json2 API, and XMLRPC support will be dropped on the next version. In order to simplify the code and avoid subsequent requests in case of errors on the json2 API, the XMLRPC fallback is stripped off from `databases.api`. In this commit, we only adapt the tests so that they don't test the fallback to XMLRPC when calling odoo.com. In the next commit, we will remove the dead code. The configuration parameter `databases.odoocom_apiuser` is removed, as well as the corresponding field in the Settings page. ### [IMP] databases: remove xmlrpc fallback for odoo.com (fixup!) With this second commit, we remove the dead code concerning the fallback to XMLRPC when calling odoo.com. ### [IMP] databases: use multidb routes to fetch KPIs on SaaS When synchronizing KPIs from databases in the new Databases application, it takes a long time to make a RPC call to each database in the list. With this commit, in the case of the SaaS, these calls are grouped by server to a dedicated route that will process the information faster, like the databases dashboard odoo.com/my/databases already does to fetch mail activities summary. Task-id: [5167731](https://www.odoo.com/odoo/project.task/5167731)
This update enhances financial reporting by providing a 'coverage ratio' for each analytic plan. This allows users to easily identify if journal items are fully distributed across their planned analytics, which is crucial for accurate audit trails and financial analysis. It addresses discrepancies arising from Odoo's partial analytic distribution capabilities.
Original PR description
The objective is to bridge the gap between journal items and analytic items in the reporting. As Odoo allows for partial analytic distribution, this creates discrepancies in the P&L and BS when filtered by an analytic plan. This features aims to provide users with a clear 'coverage ratio' per plan to identify incomplete distributions during audits. task-5887978 Forward-Port-Of: odoo/enterprise#106750
Resolved issues and error corrections
This update resolves an issue where retry attempts for Fiskaly SCU setup were incorrectly triggered by client errors, leading to confusing error messages. The fix now only retries on server errors and intelligently reuses existing SCU instances to avoid exceeding Fiskaly's signature creation limits, ensuring smoother and more reliable SCU setup.
Original PR description
- Only retry on server errors (5xx) instead of client errors (4xx), which caused confusing RetryError instead of the actual API response. - Reuse the existing active SCU when Fiskaly's limit of 1 active signature creation unit is reached (E_SCU_LIMIT_REACHED). opw-5958673
This update fixes an issue where Field Service orders were incorrectly reserving all stock moves within a delivery chain, leading to all picking steps being marked as 'Ready' instead of just the customer-bound ones. The change ensures that stock reservations are applied only to the necessary picking steps, improving order fulfillment accuracy. This resolves a conflict arising from a recent database update.
Original PR description
Since db76eb2020383, `move_ids` on sale order line is link to all stock move of a delivery chain. Meaning there is 3 moves by default for 3 steps delivery config. Creating a sale order via field service will force the reservation of the sale order moves. This will lead to all the picking being marked as "Ready" instead of only the one going to "Customer" location. Task: 5914851
This update fixes an issue where users could order unlimited quantities of rental products through the website. The change limits the available quantity to the minimum rental availability, ensuring accurate resource allocation and preventing overbooking. This improves the reliability of our rental service.
Original PR description
It is possible to order as many products as we want of a rental product that synchronizes shifts depending on a specific service Steps to reproduce: 1. Install website_sale_renting_planning module 2. Go to Rental > Products and create a new product "test" with Sales enabled, Product Type "Service", Plan Services enabled as "Developer", in the Sales tab, enable Is Published and in the Rental prices tab, create a pricing for Daily period 3. In the General Information tab, click on the internal link to "Developer" 4. Enable Sync Shifts and Rental Orders 5. Go to the eCommerce website and search for product "test" 6. You can add as many quantity of the product to your cart Issue: We don't limit the maximum quantity of the product Solution: Look through the renting availabilities of the product and set the maximum quantity to the minimum of the availabilities relevant to the renting dates selected opw-6009928
This update allows users to create pricelist rules for subscription products that also offer one-time sales. Previously, the system restricted pricelist items based on recurring invoice settings, preventing flexible pricing options. This change ensures users can accurately define pricing for hybrid subscription models.
Original PR description
Currently, the pricelist item form strictly filters out any product marked as a recurring invoice (`recurring_invoice` = True). This prevents users from defining standard pricelist rules for "hybrid" products that are subscriptions but also have `allow_one_time_sale` enabled. This commit updates the domain on `product_tmpl_id` in the pricelist item form to include an OR condition. Products are now visible if they are NOT a recurring invoice, OR if they explicitly allow one-time sales. Task: 6052066
This update corrects an error in the Luxembourg balance sheet report that was causing incorrect 'Results brought forward' values. The fix adjusts how the system calculates this line, ensuring it accurately reflects year-end financial adjustments for Luxembourg companies. This improves the reliability of financial reporting.
Original PR description
… sheet Steps to reproduce: - Use a Luxembourg company - Post a P&L result for the year and do the year-end affectation (Dr 142 / Cr 1412) - Open the Luxembourg balance sheet (full or abbreviated)…
… sheet
Steps to reproduce:
- Use a Luxembourg company
- Post a P&L result for the year and do the year-end affectation (Dr 142 / Cr 1412)
- Open the Luxembourg balance sheet (full or abbreviated)
Issue:
Line "V. Profit or loss brought forward" shows incorrect values.
Cause:
The `accounts` expression for that line used `account_codes` engine with formula `-14`, which only sums accounts by code prefix. Account 1412 ("Results brought forward (assigned)") was typed as `equity`, so its balance was carried forward as an initial balance instead of being captured as retained earnings in the formula.
Solution:
- Set account 1412 to `equity_unaffected`, consistent with account 142.
- Change the `accounts` expression of Line V in both the full and abbreviated balance sheet to use the `domain` engine: `['|', ('account_id.code', '=like', '14%'), ('account_id.account_type', '=', 'equity_unaffected')]` with subformula `-sum`. This correctly captures the balance of all 14x accounts and any `equity_unaffected` accounts, which covers the standard year-end affectation workflow.
opw-5883505This update fixes an issue where users could create serial numbers for components during manufacturing operations, even when serial number creation was disabled in settings. This change ensures that only authorized serial numbers are created, improving data accuracy and preventing potential inventory discrepancies. The fix addresses a technical oversight in the shopfloor application.
Original PR description
**Issue**: Even when creation of new Serial Numbers for components is disabled on the Manufacturing Operation Type, it is still possible to create them from the shopfloor application. **Steps to…
**Issue**: Even when creation of new Serial Numbers for components is disabled on the Manufacturing Operation Type, it is still possible to create them from the shopfloor application. **Steps to reproduce**: - Enable "Lots & Serial Numbers", on the global settings - Create two products, one tracked by unique serial number - Go to Inventory > Configuration > Warehouse Management > Operations Types - Select Manufacturing and disable "Create New Lots/Serial Numbers for Components" - Create and confirm a MO using the tracked product as component - Go to shopfloor - Click the "+" button next to the component, then "New" -> No error is raised when creating a serial number **Cause**: The `_check_create` constraint relies on `active_mo_id`: https://github.com/odoo/odoo/blob/494cdcfdf4ec166e0a643ee70a53c12c810d02b4/addons/mrp/models/stock_lot.py#L11-L19 However, the shopfloor does not pass this, in context: https://github.com/odoo/enterprise/blob/54c6252a0e13b11fc297b6828883923c0f89881a/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L193-L199 As a result, the check is bypassed. opw-6041241
This update ensures the 'Load Order' button remains hidden on Grab/GoFood orders, regardless of screen size. Previously, resizing the window would briefly show this button, which could lead to manual order changes. This change prevents unauthorized modifications and maintains the integrity of external delivery orders.
Original PR description
For Grab/GoFood orders, the "Load Order" button is replaced by "Set Food Ready" to prevent manual edits. Previously, resizing or minimizing the window caused the hidden "Load Order" button to reappear due to responsive layout overrides (e.g., mobile view CSS classes). This commit updates the visibility logic to ensure the button remains strictly hidden across all screen sizes for external delivery orders. opw-6044176