Friday, July 3, 2026
11 changes · saas-18.3
Resolved issues and error corrections
This update resolves a technical problem that could have caused incorrect updates to French tax reporting data. The fix prevents a query from failing when a specific date field was empty, ensuring accurate tax calculations and reporting for French businesses using the Odoo platform. This improves the reliability of our French tax compliance features.
Original PR description
Fixes _force_update_l10n_fr_f10_moves(). It would create a SQL query that compares a date to a bool when _pdp_get_flow_10_start_date() returned None. Forward-Port-Of: odoo/odoo#273006
This update fixes an issue where URL suggestions in the Notes app overflowed on smaller mobile devices. The fix adjusts the layout of the suggestion container to ensure it adapts to different screen sizes, providing a cleaner and more usable experience for users.
Original PR description
Step to reproduce: - Open Notes - Open the link popover - Type a URL in the URL input field Description of the issue/: - On mobile devices, URL autocomplete suggestions overflow the viewport. Cause: - The autocomplete suggestions container has a max-width of 600px. - On smaller screens, the container does not shrink to fit the available width, causing it to overflow the viewport. Solution: - Add width: 100% to the autocomplete suggestions container so it adapts to the available screen width on smaller devices while still respecting the existing max-width on larger screens. task-6201175 Forward-Port-Of: odoo/odoo#269493
This update fixes an issue where customer addresses were excessively long in form view titles and breadcrumbs, making them difficult to read. The change ensures that only the customer's name is displayed, aligning with how other fields are handled, resulting in a cleaner and more user-friendly navigation experience.
Original PR description
- Create a new Invoice; - Assign a Customer with a multiline address; - Click on the internal link (arrow icon) of the Customer field. Before this commit, the form view title and the breadcrumb would contain not only the customer's name but also their full address. This resulted in an excessively large and unreadable breadcrumb. Now, only the name is retained. This commit applies the same behavior already used in many2one fields: the display name is split by line breaks, and only the first line is kept for the title and breadcrumb. task-id 6329662 Forward-Port-Of: odoo/odoo#272550 Forward-Port-Of: odoo/odoo#272059
This update fixes an issue where the Intrastat report was incorrectly cropping the bill name, preventing full visibility of key information like the hyphenated identifier. The fix adjusts a regex pattern to allow hyphens in bill names, ensuring accurate display of all bill details in the report.
Original PR description
**Steps to reproduce:** - Install Accounting - In Accounting settings, activate "Intrastat" - Create a product with Intrastat info - Create a bill: * Product: [the created Intrastat product] *…
**Steps to reproduce:** - Install Accounting - In Accounting settings, activate "Intrastat" - Create a product with Intrastat info - Create a bill: * Product: [the created Intrastat product] * Intrastat Country: [any] * Intrastat Transport Mode: [any] - Confirm the bill - Make sure that the bill name contains a hyphen character (i.e. "-") For example, "BILL/2026-06/0001". Use the "Resequence" action from the bills list view if needed. - Go to "Accounting / Reporting / Audit Reports / Intrastat Report" - Expand the line to display the bill name **Issue:** The bill name is not fully displayed. It is cropped right before the hyphen character (i.e. BILL/2026). **Cause:** A regex is used to retrieve the bill name from the report line name, but it is only allowing "/" character. **Solution:** Just allow "-" character in addition. No other character is allowed to limit the risk of matching something that should not. opw-6299854 Forward-Port-Of: odoo/enterprise#120979
A technical issue prevented users from previewing the '2Fa New Login' template. This was caused by an assertion error triggered when the preview environment wasn't running with elevated privileges. The fix replaces the assertion with a conditional check that returns placeholder data, allowing the preview to function correctly.
Original PR description
Issue: ---------------------------------------- Clicking "Preview" on the template "2Fa New Login" causes an error. Steps to reproduce: ---------------------------------------- - Search for the mail template "Settings: 2Fa New Login" - Click "Preview" - Error in terminal - From 17.0+ the error shows in UI - From saas-18.3+, a traceback occurs whe resetting the template Cause: ---------------------------------------- There is an assert the method `_get_totp_mail_code()` to ensure it's used during 2FA. But when passing by rendering this template in preview we aren't in sudo and the assert in `_get_totp_mail_code()` raises. Solution: ---------------------------------------- We replace the `assert` by a `if` which will return fake results. opw-6333887 Forward-Port-Of: odoo/odoo#273505 Forward-Port-Of: odoo/odoo#273125
This update resolves a rare technical problem within the Odoo web interface that could occasionally cause a test to fail. The fix ensures that popovers are properly closed, preventing errors that arise when components are destroyed during the testing process. This improves the stability of the web application.
Original PR description
Add an extra step to close the popover and prevent the `Component is destroyed` error[1], which can happen during hoots cleanup, similar to the issue we see when some dialogs perform RPCs as they are being destroyed. [1]: https://runbot.odoo.com/runbot/build/115972540 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#273396 Forward-Port-Of: odoo/odoo#273085
This update fixes an issue where new time off requests were incorrectly showing a duration of 0 days due to an automation rule. The fix ensures the leave duration is accurately calculated from the requested dates, regardless of automation activity creation. This prevents incorrect time off calculations and reporting.
Original PR description
Current behavior: -- With an active automation rule (base_automation) whose action creates an activity (e.g. a "Time Off Approval" activity) on hr.leave creation, every newly created time off request…
Current behavior: -- With an active automation rule (base_automation) whose action creates an activity (e.g. a "Time Off Approval" activity) on hr.leave creation, every newly created time off request has a duration of 0 days / 0 hours, regardless of the requested dates. Expected behavior: -- The leave duration is computed from the requested dates, unaffected by the presence of an activity-creating automation rule. Steps to reproduce: -- - Create an automation rule on hr.leave, trigger "On Creation & Update". - Add an action that creates an activity (type "Time Off Approval"). - Create any time off request for an employee with a working schedule. - The request shows a duration of "0 days" (or "0 hours"). Cause of the issue: -- date_from/date_to and number_of_days/number_of_hours are stored compute fields the duration (number_of_days/number_of_hours) depends on the dates (date_from/date_to). The rule's action creates a mail.activity whose notification renders the leave's display_name. Computing display_name pulls in dashboard_warning_message, which re-enters _compute_date_from_to. Inside that in-progress compute, _compute_duration is evaluated while date_from/date_to are still False in the ORM cache, so _get_durations returns (0, 0). The dates are correct afterwards, but the duration was already computed and stored as 0, and nothing in the create flow re-triggers its compute, so a stale 0 is persisted to the database (it is only recomputed if a dependency such as the request dates or leave type is later modified). Fix: -- Once date_from/date_to are settled at the end of _compute_date_from_to, add the duration fields (number_of_days, number_of_hours, duration_display) back to the compute queue so they are recomputed against the correct dates. opw-6235902 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a usability issue in the invoice outstanding payments widget by sorting payments in descending order by date. This ensures users can easily see the most recent payments and reduces confusion when reviewing outstanding invoices. The change was driven by a user feedback request (opw-6254080).
Original PR description
Before this commit: The invoice outstanding payments widget was not sorted by date globally, which could lead to confusion for users when viewing the widget. After this commit: This commit adds a sorting mechanism to ensure that the payments are displayed in descending order based on their date and ID. opw-6254080
This update resolves an issue where the Sale Renting module wasn't properly connected to the Gantt view functionality. Previously, the module wouldn't display Gantt views correctly. This fix ensures compatibility and proper functionality for users relying on Gantt views within the Sale Renting module, aligning with recent improvements in Odoo 19 and later versions.
Original PR description
Module was introduced without a dependency on the `web_gantt` module despite using `gantt` views. Already fixed in 19+ runbot error 237883 Forward-Port-Of: odoo/enterprise#122136
This update ensures that several Odoo community add-ons (certificate, l10n_hr_edi, etc.) are correctly licensed under LGPL-3. Previously, these modules incorrectly used the enterprise license. This change aligns with the proper licensing for community-supported add-ons, clarifying legal obligations and ensuring compliance.
Original PR description
Before this commit, the license set on manifest of some modules uses the enterprise license instead of `LGPL-3` license since it is a community module. This commit changes the license to set `LGPL-3`. Fixes #205134 Forward-Port-Of: odoo/odoo#273690 Forward-Port-Of: odoo/odoo#273597
This update optimizes how Odoo forms respond to changes. Previously, opening a form triggered onchange methods multiple times for related field updates. This fix reduces redundant calls, leading to faster form loading and a smoother user experience. It's a small but important improvement for overall performance.
Original PR description
When an onchange method depends on several fields that all change at once (for example two fields that both have a default value), opening the form triggers that method once per field, even though a single call would suffice. This adds a per-pass set of already-applied onchange methods so that, within the same batch of changed fields, each method is invoked only once. Note this does not guarantee a method is called exactly once overall: it may still run again in later onchange passes; we only remove the redundant calls within a single pass. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251813