Thursday, February 12, 2026
10 changes · saas-18.2
Enhancements to existing features
This update ensures Odoo's Spanish tax reporting (l10n_es_report) complies with the latest requirements from the BOE (Boletín Oficial de la Estado) regarding the Modelo 347. A change was made to the export process to align with recent regulations, specifically addressing a lack of subsidy number data by adding placeholder zeros. This update maintains compliance with Spanish tax reporting standards.
Original PR description
reference: https://www.boe.es/buscar/doc.php?id=BOE-A-2025-25390 considering the modelo 347 As we do not have anything for the subsidy number, we just put 6 0s. opw-5926624 Forward-Port-Of: odoo/enterprise#107125
Resolved issues and error corrections
The Discuss video calling component was updated to a newer supporting service bundle. This helps keep meeting and voice/video call infrastructure current with upstream fixes, improving reliability without changing how users work.
Original PR description
https://github.com/odoo/sfu/releases/tag/v1.3.3 Forward-Port-Of: odoo/odoo#246979 Forward-Port-Of: odoo/odoo#244971
This update fixes an unreliable automated test around image handling by waiting for the image data conversion to finish explicitly. It helps reduce false failures in validation runs, making releases and maintenance checks more dependable without changing user-facing behavior.
Original PR description
Encoding the data to base64 can take some times. Before this commit we used this code: ```js await runAllTimers(); await animationFrame(); ``` Now we explicitly wait for the change to happen as awaiting an animation frame can't be enough. runbot-error-237568 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248166
Calendar events created from a dragged time slot now keep the duration users manually set before saving. This prevents confusion where an event looked correct on the calendar but showed the original, shorter duration when opened for editing.
Original PR description
Currently, an incorrect duration is displayed when the start or end time is `manually changed` during event creation. **Steps to reproduce:** - Install the `Calendar` module and open the app. - Drag…
Currently, an incorrect duration is displayed when the start or end time is `manually changed` during event creation. **Steps to reproduce:** - Install the `Calendar` module and open the app. - Drag on the calendar to create a `2-hour` time slot (quick-create popup opens). - Manually adjust the start or end time to make the event `3 hours` long. - Click `Save & Close`. - Click on the event: it correctly displays (3 hours). - Click `Edit` and observe the `Duration` value. **Observation:** The duration field shows 2 hours instead of 3 hours. **Root cause:** - The `duration` field is not available (and therefore not stored) in the `quick-create view` at [1]. - When the `stop` time is set manually, the `duration` is computed at [2]. - When the `start` time is changed, the `stop` time is computed based on the previously computed `duration` at [3]. **Fix:** This commit adds the `duration` field to the `quick-create` view as `invisible` (preventing it from being recomputed on each onchange) and `force_save`. This aligns the behavior with `19.0` by preserving the last computed duration in the front-end model, as implemented in PR [4]. [1]: https://github.com/odoo/odoo/blob/84571c03ff38ee768ed135bef3afa98511e3ab7b/addons/calendar/views/calendar_views.xml#L294-L339 [2]: https://github.com/odoo/odoo/blob/84571c03ff38ee768ed135bef3afa98511e3ab7b/addons/calendar/models/calendar_event.py#L353-L356 [3]: https://github.com/odoo/odoo/blob/84571c03ff38ee768ed135bef3afa98511e3ab7b/addons/calendar/models/calendar_event.py#L358-L374 [4]: https://github.com/odoo/odoo/pull/226909 opw-5867946 Forward-Port-Of: odoo/odoo#247193
This fix prevents module updates from failing when Odoo encounters outdated or inconsistent field cleanup data. It safely skips incompatible fields during deletion processing, improving upgrade reliability without changing user-facing behavior.
Original PR description
Description of the issue/feature this PR addresses: Fix AttributeError that occurs during module updates when processing selection field deletions. Current behavior before PR: When updating modules, an `AttributeError` occurs when trying to access the `ondelete` attribute on fields that are not Selection fields: AttributeError: 'Char' object has no attribute 'ondelete' Desired behavior after PR is merged: Add validation to check if the field type is 'selection' or 'reference' before attempting to access field.ondelete as a dictionary. Skip processing for incompatible field types to prevent AttributeError. @moduon MT-13588 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247971
A test for the Shiprocket delivery module was failing due to a default pricelist being applied, which incorrectly calculated taxes. This fix ensures that the pricelist is cleared during testing, allowing for accurate tax calculations and reliable test results. This resolves a discrepancy in the reported order total.
Original PR description
Issue
-----
`File "/data/build/enterprise/delivery_shiprocket/tests/test_delivery_shiprocket.py", line 317, in test_shiprocket_delivery_with_discounts
self.assertAlmostEqual(sale_order.amount_total, 55)
AssertionError: 32.0 != 55 within 7 places (23.0 difference)
`
Cause
-----
Test fails because a pricelist gets applied by default and overrides the taxes.
-----
Error runbot 232692
Forward-Port-Of: odoo/enterprise#105180This update ensures the 'Request Signature' menu item appears correctly on form views when a chatter is present. Previously, the system inconsistently checked for chatter, leading to the item sometimes being missing. This fix guarantees the menu item is displayed as expected for users with chatter functionality.
Original PR description
****Behavior:**** **Current:** When selecting the cog menu on certain forms, the request signature item doesn't always show even though it should. The expected behavior of this menu item is to appear only on form views with a chatter, but the way the chatter's presence was verified is inconsistent. **Solution:** On form views with a chatter, we can check its presence directly from the viewArch using the selector from the compiler registry. **Steps to reproduce:** From Timesheets: - Go to Timesheets - Open a task - The cog menu will not contain "Request Signature" From Project: - Go to Project - Select a project and open a task - The cog menu will contain "Request Signature" opw-4817423
This update fixes an issue where the total time on timesheets displayed in the list view was incorrectly formatted as a regular number instead of a time. The fix ensures that the total time is consistently displayed correctly after refreshing the list view, improving the accuracy of timesheet reporting.
Original PR description
# Steps to reproduce - Open Timesheets - Go to list view - Refresh page - Total is formatted as regular float instead of time # Cause of the issue The list view uses the `timesheet_uom_timer` widget for the `unit_amount` field. While the row entries were formatted correctly since the widget is added to the fields registry in `timesheet_uom_timer.js`, the aggregate (total sum) is not formatted in the same way because the formatters registry is missing that particular widget. Switching to the grid view and going back to the list view would solve the formatting. That is because the `timesheet_uom_timer` widget is added to the formatters registry when loading the grid view (in `timesheet_grid_uom_service.js`). We ensure the formatter is registered globally by patching the `timesheetGridUOMService` outside the grid view context, ensuring consistent aggregate formatting in list view, even after a page refresh. task-5907954 Forward-Port-Of: odoo/enterprise#107006
This update fixes an issue where the Accounts Coverage Report incorrectly flagged deprecated accounts as missing. The change removes a filter that excluded these accounts, ensuring the report accurately reflects the company's financial data. This improves the report's reliability and accuracy.
Original PR description
Purpose: Accounts Coverage Report considers only active accounts and deprecated accounts are excluded(which should be included).
Steps to reproduce:-
- Switch to company with Belgian COA.
- Open form view of P&L report and click on Accounts Coverage Report.
- Coverage report raises error message that account 667 is reported but does not exist in COA.
- Create an expense account with code 667000 arbitrarily.
- Coverage report does not raises above error.
- Now deprecate 667000 account.
- Coverage report again raises error that account 667 is reported but does not exist in COA.
Solution: remove `('deprecated', '=', False)` from domain.
task- 5906024
Forward-Port-Of: odoo/enterprise#107183
Forward-Port-Of: odoo/enterprise#107085This update fixes an issue preventing correct import of Zengin accounting files. The validation process now allows a wider range of characters, including standard hyphens and alphanumeric text, aligning with the Zengin specification. This ensures all valid Zengin files can be imported without errors.
Original PR description
Before this commit, the Zengin file import validation was permitting only digits, spaces, and half-width Katakana characters. This limitation caused valid files to fail validation if they contained standard ASCII characters, such as the standard hyphen (which differs from the Katakana prolonged sound mark) or alphanumeric text. This commit updates the validation regex to support the full range of characters allowed by the Zengin specification. The allowed character set has been expanded to include: - Uppercase alphanumeric characters (A-Z, 0-9) - Standard symbols (e.g., -, ., /, (, ), etc.) Ref: https://bqa.smbc.co.jp/faq/show/2473?site_domain=web21lite task-5928087 Forward-Port-Of: odoo/enterprise#107007