Daily updates from Odoo
Monday, February 23, 2026
11 changes · saas-18.4
Resolved issues and error corrections
This update resolves an issue where setting up accounting periods for tax returns would fail when the Invoicing module was also installed. The change ensures that a key setup process is consistently executed, regardless of which modules are used. This improves the reliability of tax return configuration.
Original PR description
To align with the changes introduced in **community PR** [1], this commit moves the `_initiate_account_onboardings()` method in the `account` module to ensure it is executed even when Invoicing is installed. [1] - https://github.com/odoo/odoo/pull/248790 sentry-7064593163 Forward-Port-Of: odoo/enterprise#107476
This update fixes a bug where inactive accounts were excluded from key financial reports (P&L, Balance Sheet, Accounts Coverage). The change adjusts how the system searches for accounts, now correctly including inactive ones in these reports. This ensures more accurate financial reporting.
Original PR description
Purpose: In P&L, Balance Sheet and Accounts Coverage Report, inactive accounts are not considered. Root cause: `deprecated` field on `account.account` is replaced with `active`, and orm search by default returns only active records. Solution: add `active_test=False` in the context. task- 5906024 Forward-Port-Of: odoo/enterprise#106956
This update resolves an issue where users within the 'Planning / User' group couldn't take open shifts. The fix ensures that the 'I Take It' button is displayed correctly for these users, allowing them to seamlessly accept shifts within the Planning app. This improves the usability of the Planning feature for all users.
Original PR description
## Issue In the Planning app, users within the *Planning / User* groups could not take open shifts. The button *"I Take It"* would not be displayed when clicking on the shift. ## Steps to reproduce…
## Issue
In the Planning app, users within the *Planning / User* groups could not take open shifts. The button *"I Take It"* would not be displayed when clicking on the shift.
## Steps to reproduce
1. Install the *Planning* (`planning`) app
2. In the Planning app, as an admin, create and publish an open shift
3. Log in as a *User*, open the *Planning* app, and click on the open shift
4. **The _"I Take It"_ button is not displayed**
When logging in as a user who is **not** part of the *Planning / User* group, the *I Take It* button is displayed.
## Cause
The condition for the *I Take It* button to be displayed is the following:
https://github.com/odoo/enterprise/blob/301e3c40c3272a6ae89a1eb4387d7d244e1dc52c/planning/views/planning_views.xml#L282-L283
The condition that makes the button invisible is `not context.get('my_planning_action')`. When the user is part of *Planning / User*, the schedule they see when opening the *Planning* app is the *"Schedule by Resource"*, which has the following context:
https://github.com/odoo/enterprise/blob/301e3c40c3272a6ae89a1eb4387d7d244e1dc52c/planning/views/planning_views.xml#L716
When a user who **is not** part of the *Plannig / User* group opens the *Planning* app, they see their own schedule, where the context is different than in the first case:
https://github.com/odoo/enterprise/blob/301e3c40c3272a6ae89a1eb4387d7d244e1dc52c/planning/views/planning_views.xml#L636
Because the `my_planning_action` property is in the context (and all the other conditions are respected), the button is displayed.
opw-5451282
Forward-Port-Of: odoo/enterprise#104919This update prevents unnecessary errors from being raised when the CODA/SODA syncing process runs automatically via a scheduled task (cron). Previously, repeated errors would halt the process, even if the servers were functioning again. Now, errors are only reported when manually triggered, ensuring smoother operation.
Original PR description
In case of a failure/downtime from the IAP/Codabox servers, an error is currently being raised. Although this is useful when manually clicking the Fetch button to see what happens, in the context of a CRON it's much less desirable as multiple failures from a CRON will automatically disable it which is not useful as the servers might be back up later on. Now, instead, we only raise if we're not in a CRON environment. opw-5922549 Forward-Port-Of: odoo/enterprise#107798
This update resolves an issue where the global invoice creation wizard was being permanently stored in the database, leading to potential performance slowdowns. By changing the wizard to a 'TransientModel,' the system now efficiently manages resources and avoids unnecessary data storage when creating invoices. This improves the overall speed and stability of the invoicing process.
Original PR description
Change to TransientModel so a wizard is not permanently stored in db when creating a global invoice. Forward-Port-Of: odoo/enterprise#107950 Forward-Port-Of: odoo/enterprise#107244
This update corrects a previous issue where GL reports were incorrectly filtering based on AML labels instead of account names. Previously, searching for an account wouldn't always return the correct lines. This change ensures GL reports accurately filter by the specified account name, improving report accuracy and usability.
Original PR description
Since 235a5160d13296328b79e4092a8b88a733628268, the GL reports line names are set from the amls name instead of the account name. This leads to wrong behavior when trying to filter the GL, either by using the search bar or opening the GL from a P&L line. Steps: - Create a move with a line using account 442000 for example - Create another move with no line using 442000 account - Set label of one line to be containing "442000" - Go to GL and input '442000' in the search bar -> The line with label '442000' in displayed This commit set the report line's name from the account name instead of the aml's name opw-5070801
This update resolves an issue where data related to Dian tax calculations (l10n_co_dian) was being reset unexpectedly. The fix ensures that key data elements are properly flushed, maintaining accurate accounting records for users in Colombia. This improves the reliability of financial reporting.
Original PR description
task-5500236
This update ensures that the order of selection options within Odoo Sign templates is consistently preserved. Previously, the system scrambled option order due to a technical issue. The fix replaces an unordered data processing method with one that maintains the original user-defined sequence, improving template usability.
Original PR description
Steps to reproduce: 1. Open a Sign template. 2. Drag a 'Selection' field onto the document. 3. In the popover, type options in a specific order (e.g., Delta, Alpha, Beta). 4. Click save. 5. Re-open or inspect the data 6. observe the order is scrambled based on Database ID. Cause: The Python method used `list(set())` which is an unordered collection, losing the user's input sequence. Furthermore, the final `search().ids` call returned records sorted by primary key (ID) rather than the provided list order. Solution: Replace `set()` with `dict.fromkeys()` to deduplicate while preserving input order. opw-5896373
This update resolves an issue where the 'Update Rental Prices' button disappeared after saving a rental order. The fix re-introduced a necessary field to ensure the button remains visible, allowing users to accurately adjust rental periods and prices. This improves the usability of the rental order management process.
Original PR description
Steps to produce: --- - Install `sale_renting` module. - Rental > Open any order > Change the rental period. - Save the record. Issue: --- - After saving the order, the `Update Rental Prices` button becomes invisible. Root cause: --- - The field `show_update_duration`, which controls the visibility of the button, is not present in the view. As a result, when the record is saved, the field is not included in the form data and its value is not properly maintained, causing the button to become invisible. - The field is removed from the view in this [commit]. Solution: --- - Added the `show_update_duration` field to the view to ensure its value is properly maintained. This allows the `Update Rental Prices` button to remain visible when applicable. [commit]: https://github.com/odoo/enterprise/commit/b90bbdef10a7a37fb065626ba995811ab388c7a1 opw-5937145 --- Forward-Port-Of: odoo/enterprise#107621
This update resolves a validation error occurring during invoice tax calculation with the Avatax service. The issue stemmed from incorrect tax data being sent, leading to calculation discrepancies. This fix ensures accurate tax calculations for BR localization invoices.
Original PR description
Steps to reproduce: - Set up a Company with BR localization - Create a product as follows: - [General Information] Product Type: Service - [Sales] LC116 Code: 14.01 - [Sales] Purpose of Use: Not applicable - [Sales] Service Code Origin: 14.01.3/168061/1524 - [Sales] Service Codes: 14.01.3/168061/1524 - Create an Invoice with Document Type "Electronic Service Invoice - NFS-e" - Add the product on the line - Compute taxes - Compute taxes again Issue: Action will be blocked by a validation error resulting from the external taxes call ``` odoo.exceptions.ValidationError: Odoo could not fetch the taxes related to Draft Invoice. Errors: Rejection: Total Installments doesnt match Total Lines ∑ installments[m]grossValue - ∑ (lines[n].lineAmount-line[n].lineTaxedDiscount) <> 0 ``` It occurs because during the call the system is considering the existing taxes on the line and it will send to the avatax service wrong amounts opw-5412456 opw-5409735
This update corrects a bug where OCR processing was incorrectly triggered on split expenses, leading to increased IAP credit usage and potential unexpected costs for users. The fix ensures OCR is only applied to the original expense document, particularly important when automatic digitization is enabled.
Original PR description
OCR should only be performed on the original document. Enabling it on splits leads to redundant OCR requests and unnecessary IAP credit consumption. This is particularly important when automatic digitization is enabled, as it triggers a paid request for every split generated, leading to unexpected costs for the user. The same bug was fixed in version 19.0 and up (commit 0688575), but it couldn't be backported as the `split_expense_origin_id` field doesn't exist in version 18.0. opw-[5930791](https://www.odoo.com/odoo/project/2068/tasks/5930791) Forward-Port-Of: odoo/enterprise#107992 Forward-Port-Of: odoo/enterprise#107789