Friday, April 17, 2026
14 changes · saas-18.2
Resolved issues and error corrections
Mercado Pago payment notifications now correctly reach Odoo even when an invoice reference contains slashes, such as INV/2026/00001. This prevents valid payment updates from being rejected with a not found error, helping invoices reconcile more reliably.
Original PR description
Currently, the mercado_pago_webhook http route only takes into consideration 1 url segment. This means that invoices with references like INV/2026/00001 don't match any defined route and the server returns a 404. /payment/mercado_pago/webhook/S00001 => OK /payment/mercado_pago/webhook/INV/2026/00001 => KO This commit allows references with slashes to be matched by the route by capturing the entire remaining url path including the slashes. /payment/mercado_pago/webhook/S00001 => OK /payment/mercado_pago/webhook/INV/2026/00001 => OK opw-6035161 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259378
Number fields in the domain selector and expression editor now display using the user's configured decimal and thousands separators. This makes values easier to read and reduces confusion for users working in regions with different number formats, while keeping the underlying expressions unchanged.
Original PR description
Before this commit, the domain selector (and expression editor) did not format numbers according to the localization parameters (decimal and thousands separators), while the parsing step did. After this commit, the value is displayed in the correct format to the user, while the expression remains unchanged. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258287
Invoice emails now name dynamic report attachments using each report's configured printed name. This keeps customer-facing attachments consistent with business settings while preserving the existing default naming when no custom name is set.
Original PR description
When sending an invoice by email template, dynamic report attachments do not use their configured Printed Report Name. Instead, they fall back to a default naming pattern (e.g. report name + invoice…
When sending an invoice by email template, dynamic report attachments do not use their configured Printed Report Name. Instead, they fall back to a default naming pattern (e.g. report name + invoice number). This is due to a difference in flow: sales use the standard mail.compose.message wizard, which correctly applies each report’s print_report_name, while invoices use the dedicated account.move.send flow. In this flow, dynamic report filenames are not computed from the report itself. To fix this, the send flow is updated so _get_placeholder_mail_template_dynamic_attachments_data computes the filename from each dynamic report. When a print_report_name is defined, it is used. Otherwise, the previous fallback behavior is preserved. The fix will ensure extra dynamic reports follow their configured printed name. Steps to reproduce: 1. Go to Settings > Technical > Reporting > Reports and duplicate the standard Invoice report. 2. In the duplicated report, set a custom value in Printed Report Name (e.g. 'CUSTOM_NAME_TEST'). 3. Go to Settings > Technical > Email > Templates and open “Invoice: Sending”. 4. Add the duplicated report under Dynamic Reports. 5. Create a customer invoice and confirm it. 3. Click Send (or Send & Print) to open the email preview. Related Ticket: opw-6058716 Forward-Port-Of: odoo/odoo#259267
A typo was corrected in a system warning message about database rules. This improves clarity for administrators and developers who may see the warning, with no impact on everyday business workflows.
Original PR description
In this commit: --------------- - Corrected a typo in the SQL constraint warning message, updated `model.Constraint` to `models.constraint`.
The HTML editor table menu now refreshes its available row and column actions whenever the user selects a different table cell. This prevents outdated menu options from appearing, making table editing more reliable and less confusing.
Original PR description
After this commit [1], setup is executed only on the initial mount of the table menu and not on subsequent target cell changes. As a result, colItems, rowItems, and other values found in setup become stale, causing the menu to display options that do not reflect the current target cell. This commit moves the necessary values from setup into useEffect so they update correctly when the target cell changes. task-6111986 [1]: https://github.com/odoo/odoo/commit/7d523d6402c9bff3c2e4bcd0329f486a2d0f45ec Backport of Commit https://github.com/odoo/odoo/commit/729c45ddf3d1e377507d93997c5ca45984d64d75 Forward-Port-Of: odoo/odoo#258590
The Inventory Move History screen no longer appears to let users edit a reference value that cannot actually be saved. This prevents confusion by making the field behavior match the real business rule: references are for viewing only in this context.
Original PR description
### Issue before this commit: Before this commit, the Reference field displayed on stock.move.line was editable in the user interface, even if the modification made by the user was not persisted.…
### Issue before this commit: Before this commit, the Reference field displayed on stock.move.line was editable in the user interface, even if the modification made by the user was not persisted. After saving and reloading the Move History view, the original value was restored. ### Steps to reproduce the issue: 1. Go to Move history in Inventory app 2. Try to change the name of a line and save 3. If you go back to the Move history you can see that the name is not changed ### Cause of the issue: The issue was caused by a mismatch between the stock.move.line.reference field and its target field stock.move.reference. The field on stock.move.line is a related field that appears editable (readonly=False), but the underlying stock.move.reference field was not writable. As a result, user could edit the field but the modifications were ignored, preventing changes from being effectively saved. ### Reason to introduce the fix: The fix ensures that the reference field in stock.move and in stock.move.line are readonly. opw-6055708 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Indian localization now requires an aggregate period whenever aggregate limits are enabled. This prevents invoice creation from failing when that required period was accidentally cleared.
Original PR description
Previously, if `is_aggregate_limit` was set to True while `aggregate_period` was left empty, it would raise a traceback during invoice creation. Although `aggregate_period` has a default value, it can still be manually cleared. With this commit, `aggregate_period` is enforced as mandatory whenever `is_aggregate_limit` is enabled, preventing such errors. Forward-Port-Of: odoo/odoo#259634
Fixes an issue where grouped list views could show the configured count limit instead of the real number of records after opening a group or moving to the next page. Users now see consistent, accurate totals in list pagers, reducing confusion when navigating grouped records.
Original PR description
When a pager is needed in a grouped list view and if the total number of record is greater than the `count_limit` (by default equal to 10000); opening the group or pressing the "Next" button will display the `count_limit` in the Pager.
This behavior can be optimized since the `web_read_group` call already computed the total count.
This commit allow the grouped list pager to display the total record count if it was already computed.
Steps to reproduce:
in a list view with 10 records, all in the same group for simplicity:
```xml
<list limit="2" count_limit="8">
<field name="foo"/>
</list>
```
- group the view by "foo" => The pager displays: `"1-2 / 10"`
- click on the 'next' button of the pager => The pager displays: `"3-4 / 8"`
8, the `count_limit` is shown instead of 10, the number of records in the group.
task-6053705
Forward-Port-Of: odoo/odoo#259562This fix prevents the Danish localization migration from failing when an account has no code set. It helps businesses complete upgrades reliably without manual intervention for this specific data condition.
Original PR description
From https://github.com/odoo/odoo/pull/256541.
```yml
File "/home/.../odoo/addons/l10n_dk/migrations/1.4/end-migrate.py", line 102, in migrate
if len(account.code) < 6:
TypeError: object of type 'bool' has no len()
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#258399
Forward-Port-Of: odoo/odoo#258299This change adjusts an automated test for the HTML editor so it behaves consistently across runs. It helps reduce false failures in the testing pipeline, making releases and maintenance more reliable without changing end-user functionality.
Original PR description
My last desperate fix attempt did not fix the issue so here is yet another desperate fix attempt. I have seen issues related to the use of `setContent` just to set the selection in the past so I hope it might be that. It's the only noticeable change between this test and the others, be it icon tests or color selector ones. runbot-242333 Forward-Port-Of: odoo/odoo#259544
This fix prevents outdated internal data from being reused after a module is uninstalled. It helps keep Odoo stable and avoids incorrect behavior in later operations that depend on updated model information.
Original PR description
When uninstalling a module, the ORM may replace field objects in the registry via a prefetch patch to avoid fetching deleted fields. The previous code only called lazy_property.reset_all(), which resets lazy-property caches, but left _field_trigger_trees and _is_modifying_relations intact. Those structures still held references to the old field objects, and could be consulted by subsequent ORM operations, leading to incorrect trigger resolution or relation tracking. Clear both caches whenever a shared field has been patched so all registry state stays consistent with the new field objects. runbot-242251 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259820
This update fixes a bug that prevented users from saving appointments when removing the organizer. The issue stemmed from a template rendering error triggered by a missing user ID. This change ensures appointments can be saved correctly, improving appointment scheduling functionality.
Original PR description
Currently an error is generated when the user tries to save an appointment as follows: - Install the appointment_google_calendar module without demo data - Create a new appointment as below: - Remove…
Currently an error is generated when the user tries to save an
appointment as follows:
- Install the appointment_google_calendar module without demo data
- Create a new appointment as below:
- Remove Organizer (user_id)
- Set the Google Meet link inside VideocallURL, e.g., https://meet.google.com/aaa-aaa-aaa
- An error occurs in the log and a message is shown to the user when save the record
- Also, an error occurs when trying to preview `Appointment: Attendee Invitation`
after creating appointment as follows:
- Set the Google Meet link inside Videocall URL > save
- Remove Organizer (user_id)
Error:
```
test odoo.addons.mail.models.mail_render_mixin: Failed to render QWeb template for Mail Template: 'Appointment: Appointment Booked' (ID: 12) - Context language:en_US
Target Model: calendar.event
Error: Error while render the template
ValueError: Expected singleton: res.users()
```
This is because the method `is_google_calendar_synced` expected a single
record, but since we removed `user_id` from the event (appointment),
it will generate a singleton error.
This commit will fix the above issue by not calling `is_google_calendar_synced`
when the event does not have `user_id`.
sentry-7393595716
Forward-Port-Of: odoo/enterprise#113966This update resolves a test failure caused by an unnecessary calculation of a holiday pay field. The fix removes tracking from the field, ensuring it's only computed when needed, preventing early computations and restoring accurate test results. This improves the stability of the Belgian payroll module.
Original PR description
…ield The computed, non-stored field `l10n_be_holiday_pay_recovered_n1` had tracking enabled. When writing to any field on the employee, the `write` method calls `_track_prepare` for tracked fields if `mail_notrack` is not set in the context. `_track_prepare` reads the current value of tracked fields to store initial values. Because `l10n_be_holiday_pay_recovered_n1` is non-stored with no dependencies, this triggered a computation at the very beginning of the test, before payslips existed. Later, when payslips were created, the field was never recomputed, causing incorrect values and test failures. Previously, the `tracking_disable` context prevented early computation. The fix removes the tracking attribute entirely, so the field is only computed when accessed, avoiding premature reads and fixing the tests. task: 6095445 Forward-Port-Of: odoo/enterprise#113015
This update resolves an issue where negative numbers in accounting reports (like customer statements) were incorrectly split across lines, making them difficult to read. The fix ensures that negative numbers are displayed as a single line, maintaining proper formatting and clarity in printed reports. This improves the user experience and accuracy of financial statements.
Original PR description
When printing accounting reports such as customer statements, a negative number may be split across two lines, leaving the minus sign on the first line and the amount on the second. Steps to reproduce: - Make an invoice for [Partner] with a total of 10.0 - Make another invoice for [Partner] with a total of 100.0 - Create a credit note for this last invoice - Open the customer statement report for [Partner] - Print PDF Issue: The first line of the partner section has fewer digits than the amounts of the subsequent journal items. On pdf, the column width is based on the smaller line, causing the longer negative strings to wrap and separate the minus sign from the amount. opw-5951300 Forward-Port-Of: odoo/enterprise#113727