Odoo Changelog — 2026-07-02

Thursday, July 2, 2026

5 changes · saas-18.2

Bug Fixes(5)

Resolved issues and error corrections

[FIX] l10n_mx_reports: correct node order for SAT XML report

Enterprisesaas-18.2l10n_mx_reports

The Mexican trial balance XML report now follows the SAT-recommended order for account nodes. This brings the exported file in line with government formatting expectations and helps avoid issues when reviewing or submitting the report.

Original PR description

**Steps to reproduce:** - Install the `l10n_mx_reports` module and switch to a Mexican company. - Navigate to Accounting > Reporting > Trial Balance. - From the dropdown menu, click `SAT (XML)`. -…

**Steps to reproduce:**
- Install the `l10n_mx_reports` module and switch to a Mexican company.
- Navigate to Accounting > Reporting > Trial Balance.
- From the dropdown menu, click `SAT (XML)`.
- Open the generated XML file and inspect the `<BCE:Ctas>` nodes.

**Observation:**
- The generated XML uses the following attribute order: `Debe > NumCta > Haber > SaldoFin > SaldoIni`
- However, the SAT-recommended structure is: `NumCta > SaldoIni > Debe > Haber > SaldoFin`

**Root Cause:**
At [1], the attributes of the `<BCE:Ctas>` node are defined in an order 
that differs from the SAT-recommended structure. While the XML remains 
valid, the generated report does not match the layout recommended by the 
Mexican government specification.

**Fix:**
This commit reorders the `<BCE:Ctas>` attributes to follow the 
SAT-recommended structure, aligning the generated XML with 
the behavior introduced at [2] for `saas-19.3`.

backport-of: https://github.com/odoo/enterprise/pull/115374

[1]:
https://github.com/odoo/enterprise/blob/cb9c19272309d793379fa4d23145162f72fa5552/l10n_mx_reports/data/templates/cfdibalance.xml#L15-L20

[2]:
https://github.com/odoo/enterprise/blob/acf0929a88ec788aecd44f6b4c647e468dc0a319/l10n_mx_reports/data/templates/cfdibalance.xml#L17-L22

opw-6297711

Forward-Port-Of: odoo/enterprise#122376
Forward-Port-Of: odoo/enterprise#121440

#localization#Mexico#accounting#XML#SAT

[FIX] l10n_no_saft: prevent wrong slicing

PR #122169

Enterprisesaas-18.2l10n_no_saftMEDIUM

This fix ensures the SAF-T export uses the correct official grouping code when account numbers are sliced. It prevents wrong codes from appearing in the general ledger export, improving the accuracy of accounting reports.

Original PR description

Steps to reproduce:
- change 1920 Banck account to 19204321
- go in general ledger and export to "SAF-T"

Issue:
The grouping code is 4321

Grouping code should match official grouping code.

As a matter of fact the chart of account seems to match thos grouping account if we slice them correctly.

opw-6285078

Forward-Port-Of: odoo/enterprise#121932

#accounting#saft#export#reporting

[FIX] appointment_google_reserve: name booker from google payload

PR #121423

Enterprisesaas-18.2appointment_google_reserveMEDIUM

Bookings made through Reserve with Google will now create contacts using the customer’s first and last name from Google, instead of falling back to the email address. This improves the accuracy of contact records and makes appointment details display the customer’s real name in Odoo.

Original PR description

When a customer books through Reserve with Google, the createBooking payload carries the booker given_name and family_name next to the email, but the handler passed only the normalized email to…

When a customer books through Reserve with Google, the createBooking payload carries the booker given_name and family_name next to the email, but the handler passed only the normalized email to _mail_find_partner_from_emails. The new res.partner was therefore created with its name falling back to the email, see
 
https://github.com/odoo/odoo/blob/aa7b5921191a0ff53ef1cc32af99fe458c45c0da/addons/mail/models/res_partner.py#L177

That name then flows into the calendar.event name, the attendee common_name and the contact details, all showing the email instead of the customer name. The module has read neither field since it was added in https://github.com/odoo/enterprise/commit/2e855b910173b56e8501d0ebe9ee6f83ac5845bc.

Build the booker name from given_name and family_name and pass it with the email through formataddr in google_reserve_booking_create, so a newly created partner is named after the customer. A partner matched on an existing email keeps its current name.

Steps to reproduce:
1. Enable Reserve with Google on an appointment type.
2. Book a slot from Google Maps with given name John and family name Doe.
3. Open the created booking and its contact in Odoo.

=> the contact name is the email instead of John Doe

Ticket [link](https://www.odoo.com/odoo/project/49/tasks/6232318)
opw-6232318

Forward-Port-Of: odoo/enterprise#120604

#appointments#google#contacts#customer-name#calendar

[FIX] web_studio: fix active_id in studio's url, to and from

PR #122405

Enterprisesaas-18.2web_studio

This update corrects a bug where the Studio URL was incorrectly formatted, causing errors when navigating back or loading Studio again. The fix ensures the active project ID is correctly set, preventing issues with Studio functionality and improving the user experience.

Original PR description

Go on a project, then open its task list view
Open studio with the menu item.

At this point, studio is open but the url looks like: `/odoo/project/5/tasks/studio/5`
the last `/5` is wrong ; this commit fixes this.

Then, hit the browser's back button.
There is an error because the active_id was not correctly set when leaving studio that way

Try loading `/odoo/project/5/tasks/studio`, again, there is an error because the active_id is read from the wrong object

#studio#url#navigation

[FIX] sign: send notification to inbox when request is signed

PR #122519

Enterprisesaas-18.2signMEDIUM

This update fixes an issue where users weren't receiving notifications when a sign request was completed after they'd set their notification preference to 'Handle in Odoo'. The fix ensures that the sender receives a notification, improving transparency and workflow efficiency. This resolves a previous bug impacting the sign request process.

Original PR description

## Issue When a user sets their notification to "Handle in Odoo" (`inbox`) and a sign requested is completed, they do not receive the expected notification. ## Steps to reproduce 1. Install *Sign*…

## Issue
When a user sets their notification to "Handle in Odoo" (`inbox`) and a sign requested is completed, they do not receive the expected notification.

## Steps to reproduce
1. Install *Sign* (`sign`)
2. Sets the current user's notification preference to "Handle in Odoo" (`inbox`)
3. Create a sign request and send it to Marc Demo
4. As Marc Demo, sign the request
5. **The user who sent the sign request did not receive a notification to notify them that the request was signed.**

## Fix
This is a partial backport of both https://github.com/odoo/enterprise/commit/463d6a2aae536356e6dee6b902f2e881dbc4fbda (saas-18.2) and a related fix https://github.com/odoo/enterprise/commit/41395dba4fd31222f5fd9fc94a84c977cf9334f9 (19.0). Before the first commit, users would not receive inbox notification when sign requests would be completed.

## Note to reviewer
The issue only occurs in 18.0, as it is fixed by https://github.com/odoo/enterprise/commit/463d6a2aae536356e6dee6b902f2e881dbc4fbda in 18.2, but we can backport the fix from https://github.com/odoo/enterprise/commit/41395dba4fd31222f5fd9fc94a84c977cf9334f9 from 18.2 to 18.4 if desired.

opw-6251702

Forward-Port-Of: odoo/enterprise#120740

#sign#notifications#workflow

**Steps to reproduce:** - Install the `l10n_mx_reports` module and switch to a Mexican company. - Navigate to Accounting > Reporting > Trial Balance. - From the dropdown menu, click `SAT (XML)`. - Open the generated XML file and inspect the `<BCE:Ctas>` nodes. **Observation:** - The generated XML uses the following attribute order: `Debe > NumCta > Haber > SaldoFin > SaldoIni` - However, the SAT-recommended structure is: `NumCta > SaldoIni > Debe > Haber > SaldoFin` **Root Cause:** At [1], the attributes of the `<BCE:Ctas>` node are defined in an order that differs from the SAT-recommended structure. While the XML remains valid, the generated report does not match the layout recommended by the Mexican government specification. **Fix:** This commit reorders the `<BCE:Ctas>` attributes to follow the SAT-recommended structure, aligning the generated XML with the behavior introduced at [2] for `saas-19.3`. backport-of: https://github.com/odoo/enterprise/pull/115374 [1]: https://github.com/odoo/enterprise/blob/cb9c19272309d793379fa4d23145162f72fa5552/l10n_mx_reports/data/templates/cfdibalance.xml#L15-L20 [2]: https://github.com/odoo/enterprise/blob/acf0929a88ec788aecd44f6b4c647e468dc0a319/l10n_mx_reports/data/templates/cfdibalance.xml#L17-L22 opw-6297711 Forward-Port-Of: odoo/enterprise#122376 Forward-Port-Of: odoo/enterprise#121440

Steps to reproduce: - change 1920 Banck account to 19204321 - go in general ledger and export to "SAF-T" Issue: The grouping code is 4321 Grouping code should match official grouping code. As a matter of fact the chart of account seems to match thos grouping account if we slice them correctly. opw-6285078 Forward-Port-Of: odoo/enterprise#121932

When a customer books through Reserve with Google, the createBooking payload carries the booker given_name and family_name next to the email, but the handler passed only the normalized email to _mail_find_partner_from_emails. The new res.partner was therefore created with its name falling back to the email, see https://github.com/odoo/odoo/blob/aa7b5921191a0ff53ef1cc32af99fe458c45c0da/addons/mail/models/res_partner.py#L177 That name then flows into the calendar.event name, the attendee common_name and the contact details, all showing the email instead of the customer name. The module has read neither field since it was added in https://github.com/odoo/enterprise/commit/2e855b910173b56e8501d0ebe9ee6f83ac5845bc. Build the booker name from given_name and family_name and pass it with the email through formataddr in google_reserve_booking_create, so a newly created partner is named after the customer. A partner matched on an existing email keeps its current name. Steps to reproduce: 1. Enable Reserve with Google on an appointment type. 2. Book a slot from Google Maps with given name John and family name Doe. 3. Open the created booking and its contact in Odoo. => the contact name is the email instead of John Doe Ticket [link](https://www.odoo.com/odoo/project/49/tasks/6232318) opw-6232318 Forward-Port-Of: odoo/enterprise#120604

Go on a project, then open its task list view Open studio with the menu item. At this point, studio is open but the url looks like: `/odoo/project/5/tasks/studio/5` the last `/5` is wrong ; this commit fixes this. Then, hit the browser's back button. There is an error because the active_id was not correctly set when leaving studio that way Try loading `/odoo/project/5/tasks/studio`, again, there is an error because the active_id is read from the wrong object

## Issue When a user sets their notification to "Handle in Odoo" (`inbox`) and a sign requested is completed, they do not receive the expected notification. ## Steps to reproduce 1. Install *Sign* (`sign`) 2. Sets the current user's notification preference to "Handle in Odoo" (`inbox`) 3. Create a sign request and send it to Marc Demo 4. As Marc Demo, sign the request 5. **The user who sent the sign request did not receive a notification to notify them that the request was signed.** ## Fix This is a partial backport of both https://github.com/odoo/enterprise/commit/463d6a2aae536356e6dee6b902f2e881dbc4fbda (saas-18.2) and a related fix https://github.com/odoo/enterprise/commit/41395dba4fd31222f5fd9fc94a84c977cf9334f9 (19.0). Before the first commit, users would not receive inbox notification when sign requests would be completed. ## Note to reviewer The issue only occurs in 18.0, as it is fixed by https://github.com/odoo/enterprise/commit/463d6a2aae536356e6dee6b902f2e881dbc4fbda in 18.2, but we can backport the fix from https://github.com/odoo/enterprise/commit/41395dba4fd31222f5fd9fc94a84c977cf9334f9 from 18.2 to 18.4 if desired. opw-6251702 Forward-Port-Of: odoo/enterprise#120740