Odoo Changelog — 2026-04-28

Tuesday, April 28, 2026

7 changes · saas-18.4

Bug Fixes(7)

Resolved issues and error corrections

[IMP] iap_extract: change email template address

Enterprisesaas-18.4iap_extract

This change updates the email address used for sending automated notifications from Odoo to noreply@odoo.com. Previously, clients responded to iap@odoo.com, which was causing confusion and misdirected replies. This update ensures all support emails go to the correct, designated address.

Original PR description

The current mail address is iap@odoo.com so some client respond to the automatic mail.

This fix change it to noreply@odoo.com

Task-6086556

Forward-Port-Of: odoo/enterprise#114712
Forward-Port-Of: odoo/enterprise#114097

#email#support#noreply

[FIX] l10n_mx_edi: allow copy of invoice_origin in cancelled invoice

PR #115352

Enterprisesaas-18.4l10n_mx_ediMEDIUM

This update ensures that the 'Source' (origin) field is correctly populated on replacement invoices generated through the cancel process in Mexico. Previously, this information was missing, hindering traceability. The fix explicitly copies the original invoice's information, maintaining accurate links and ensuring compliance.

Original PR description

### Issue before this commit:
The "Source" (origin) field was missing from the PDF of replacement invoices. While the original invoice correctly displayed the Sales Order reference, the new invoice generated through the request cancel process had an empty origin field.

### Steps to reproduce the issue:
1. Download Sales and l10n_mx
2. Set a UNSPSC Category for one product
3. Go to Sales, create a new Quotation and confirm it
4. Create invoice, confirm and send & print
5. Request cancel button -> create replacement invoice
6. In the new invoice there is no source origin invoice

### Cause of the issue:
The invoice_origin field is defined with copy=False. Since the replacement logic uses the copy_data method without explicitly passing the origin value, the field was automatically cleared during the creation of the new invoice.

### Reason to introduce the fix:
To ensure document traceability, the fix explicitly passes the invoice_origin from the original invoice to the replacement. This maintains the link to the Sales Order in the database and ensures the "Source" label appears on the printed PDF.

opw-6070016

Forward-Port-Of: odoo/enterprise#114099

#Mexico#EDI#Invoice Cancellation#Compliance

[FIX] l10n_lu_reports: Mismatched TransactionID in FAIA export

PR #115294

Enterprisesaas-18.4l10n_lu_reports

This update corrects a mismatch in transaction IDs when exporting financial data (FAIA) for Luxembourg. Previously, the system used different ID formats, leading to potential errors in reporting. This change ensures all transaction IDs align, improving data accuracy and reliability for financial reporting.

Original PR description

The Invoice/TransactionID element in SourceDocuments/SalesInvoices and SourceDocuments/PurchaseInvoices must match the corresponding Transaction/TransactionID in the GeneralLedgerEntries section. As the latter uses the entry name since PR odoo#58728, the former should too.

opw-6111343, opw-542729

Forward-Port-Of: odoo/enterprise#113846

#reporting#financial#Luxembourg

[FIX] sale_subscription: use new helper method

PR #115381

Enterprisesaas-18.4sale_subscription

This update resolves a problem where portal users were incorrectly seeing the 'View Timesheets' button, even without the necessary permissions. The fix utilizes a new helper method to accurately control button visibility, ensuring users only see options they are authorized to access. This improves the user experience and prevents potential confusion.

Original PR description

**Issue:**
   The 'View Timesheets' button is shown to the portal user even though they don’t have access to view timesheets.

 Currently, we have added _sale_order_get_page_view_values in the sale module, which is overridden in sale_timesheet.
 We are using it here.

 task-4745519

Forward-Port-Of: odoo/enterprise#115193
Forward-Port-Of: odoo/enterprise#113481

#user experience#permissions

[FIX] l10n_in_reports_gstr: fix vendor invoice fetch cron for multi-company

PR #115312

Enterprisesaas-18.4accountMEDIUM

This update resolves an issue where the automated reporting cron job for vendor invoices didn't correctly identify the target company in multi-company setups. The fix ensures invoices are fetched from the correct company, preventing errors and improving the reliability of the reporting process. This ensures accurate reporting across all company structures.

Original PR description

In a multi-company context, the cron might be run with a user having a default company that is not the same as the target moves companies, maybe raising a `RedirectionWarning` (if the current company is not fully set-up).

This commit ensure to fetch the invoice in move's target company.

opw-5225553

Forward-Port-Of: odoo/enterprise#115192
Forward-Port-Of: odoo/enterprise#113254

#reporting#multi-company#invoice

[FIX] stock_barcode_mrp: preserve qty, lock UoM

PR #115059

Enterprisesaas-18.4stockMEDIUM

This update resolves two bugs impacting the Barcode app's handling of Manufacturing Orders. Previously, changing the UoM after confirmation or saving changes to the 'Produce Quantity' would be lost. This fix ensures that UoM changes are correctly applied and that entered production quantities are preserved, improving data consistency and workflow accuracy.

Original PR description

### Issue Two bugs reported in the Barcode app / Manufacturing Order flow: **1. UoM change after confirm leaves MO inconsistent** Changing the UoM on a confirmed MO via the Barcode app does not…

### Issue
Two bugs reported in the Barcode app / Manufacturing Order flow:

**1. UoM change after confirm leaves MO inconsistent** Changing the UoM on a confirmed MO via the Barcode app does not recalculate `product_qty` / `qty_producing`. The backend locks the UoM after confirm — the Barcode view did not.

**2. `qty_producing` reset on wizard open/close**
Typing a value in `qty_producing` then opening the "Change Qty to Produce" widget (even closing without saving) caused the typed value to vanish. Root cause: the widget's `onClose` calls `env.model.load()`, which refetches from DB and discards any unsaved form edits.

### Fix
- `product_uom_id` in the Barcode MO form is now readonly once `state != 'draft'`, matching the backend.
- `openChangeQtyWizard` now saves the record before opening the wizard, so pending edits survive the reload.

### Steps to reproduce
**UoM bug**
1. Create an MO, confirm it.
2. Open it in the Barcode app.
3. Try to change the UoM → it was editable (bug).

**Qty reset bug**
1. Open a confirmed MO in the Barcode app, go to the header product page.
2. Type a value in `qty_producing` (e.g. `3`).
3. Click the `/ X` button next to it (opens the Change Qty wizard) then close it without clicking "Set Quantity".
4. `qty_producing` reverts to its previous value (bug).

### After the fix
- UoM field is greyed out once the MO is confirmed.
- Typed value in `qty_producing` is preserved after opening and closing the wizard.

opw-5809178

Forward-Port-Of: odoo/enterprise#114452
Forward-Port-Of: odoo/enterprise#114075

#barcode#mrp#production#uom#quantity

[FIX] account_reports: Use alias with column

PR #115311

Enterprisesaas-18.4account_reports

This update corrects a potential error in the account reports module where duplicate 'state' field names (from custom modules) could cause database conflicts. The fix ensures that column references are explicitly aliased, preventing ambiguous column errors and ensuring accurate report generation. This improves stability and reliability for our clients.

Original PR description

Issue:
-------
There are cases where clients might have the same named 'state' field/column for custom modules in the models 'res.partner' or 'account.fiscal.position' and therefore they might get conflicted with the standard one's when the below query executes,
https://github.com/odoo/enterprise/pull/84391/changes#diff-2f90e40d6e7b35681a4af03037e8e5ee0fddab2ba0876d9f148bf79786a91c29R1359 and can cause
```
File "/home/odoo/src/enterprise/account_reports/models/account_return.py", line
2204, in _check_suite_common_vat_report
self.env.cr.execute(SQL(
File "/home/odoo/src/odoo/odoo/sql_db.py", line 433, in execute
self._obj.execute(query, params)
psycopg2.errors.AmbiguousColumn: column reference "state" is ambiguous
LINE 9: state = 'posted'
```

Solution:
------------
Use the corresponding alias while mentioning the column i.e; `move.state = 'posted'`

OPW - 6044665

Forward-Port-Of: odoo/enterprise#114341

#reporting#database#stability

The current mail address is iap@odoo.com so some client respond to the automatic mail. This fix change it to noreply@odoo.com Task-6086556 Forward-Port-Of: odoo/enterprise#114712 Forward-Port-Of: odoo/enterprise#114097

### Issue before this commit: The "Source" (origin) field was missing from the PDF of replacement invoices. While the original invoice correctly displayed the Sales Order reference, the new invoice generated through the request cancel process had an empty origin field. ### Steps to reproduce the issue: 1. Download Sales and l10n_mx 2. Set a UNSPSC Category for one product 3. Go to Sales, create a new Quotation and confirm it 4. Create invoice, confirm and send & print 5. Request cancel button -> create replacement invoice 6. In the new invoice there is no source origin invoice ### Cause of the issue: The invoice_origin field is defined with copy=False. Since the replacement logic uses the copy_data method without explicitly passing the origin value, the field was automatically cleared during the creation of the new invoice. ### Reason to introduce the fix: To ensure document traceability, the fix explicitly passes the invoice_origin from the original invoice to the replacement. This maintains the link to the Sales Order in the database and ensures the "Source" label appears on the printed PDF. opw-6070016 Forward-Port-Of: odoo/enterprise#114099

The Invoice/TransactionID element in SourceDocuments/SalesInvoices and SourceDocuments/PurchaseInvoices must match the corresponding Transaction/TransactionID in the GeneralLedgerEntries section. As the latter uses the entry name since PR odoo#58728, the former should too. opw-6111343, opw-542729 Forward-Port-Of: odoo/enterprise#113846

**Issue:** The 'View Timesheets' button is shown to the portal user even though they don’t have access to view timesheets. Currently, we have added _sale_order_get_page_view_values in the sale module, which is overridden in sale_timesheet. We are using it here. task-4745519 Forward-Port-Of: odoo/enterprise#115193 Forward-Port-Of: odoo/enterprise#113481

In a multi-company context, the cron might be run with a user having a default company that is not the same as the target moves companies, maybe raising a `RedirectionWarning` (if the current company is not fully set-up). This commit ensure to fetch the invoice in move's target company. opw-5225553 Forward-Port-Of: odoo/enterprise#115192 Forward-Port-Of: odoo/enterprise#113254

### Issue Two bugs reported in the Barcode app / Manufacturing Order flow: **1. UoM change after confirm leaves MO inconsistent** Changing the UoM on a confirmed MO via the Barcode app does not recalculate `product_qty` / `qty_producing`. The backend locks the UoM after confirm — the Barcode view did not. **2. `qty_producing` reset on wizard open/close** Typing a value in `qty_producing` then opening the "Change Qty to Produce" widget (even closing without saving) caused the typed value to vanish. Root cause: the widget's `onClose` calls `env.model.load()`, which refetches from DB and discards any unsaved form edits. ### Fix - `product_uom_id` in the Barcode MO form is now readonly once `state != 'draft'`, matching the backend. - `openChangeQtyWizard` now saves the record before opening the wizard, so pending edits survive the reload. ### Steps to reproduce **UoM bug** 1. Create an MO, confirm it. 2. Open it in the Barcode app. 3. Try to change the UoM → it was editable (bug). **Qty reset bug** 1. Open a confirmed MO in the Barcode app, go to the header product page. 2. Type a value in `qty_producing` (e.g. `3`). 3. Click the `/ X` button next to it (opens the Change Qty wizard) then close it without clicking "Set Quantity". 4. `qty_producing` reverts to its previous value (bug). ### After the fix - UoM field is greyed out once the MO is confirmed. - Typed value in `qty_producing` is preserved after opening and closing the wizard. opw-5809178 Forward-Port-Of: odoo/enterprise#114452 Forward-Port-Of: odoo/enterprise#114075

Issue: ------- There are cases where clients might have the same named 'state' field/column for custom modules in the models 'res.partner' or 'account.fiscal.position' and therefore they might get conflicted with the standard one's when the below query executes, https://github.com/odoo/enterprise/pull/84391/changes#diff-2f90e40d6e7b35681a4af03037e8e5ee0fddab2ba0876d9f148bf79786a91c29R1359 and can cause ``` File "/home/odoo/src/enterprise/account_reports/models/account_return.py", line 2204, in _check_suite_common_vat_report self.env.cr.execute(SQL( File "/home/odoo/src/odoo/odoo/sql_db.py", line 433, in execute self._obj.execute(query, params) psycopg2.errors.AmbiguousColumn: column reference "state" is ambiguous LINE 9: state = 'posted' ``` Solution: ------------ Use the corresponding alias while mentioning the column i.e; `move.state = 'posted'` OPW - 6044665 Forward-Port-Of: odoo/enterprise#114341