Thursday, June 25, 2026
8 changes · saas-18.2
Resolved issues and error corrections
UBL invoice imports now ignore valid invoice lines that have zero quantity and zero value instead of failing with an error. This prevents import interruptions for affected supplier invoices while preserving the meaningful invoice data.
Original PR description
### Issue: Importing a UBL invoice containing a line with `LineExtensionAmount=0`, `InvoicedQuantity=0` and a non-zero `PriceAmount` failed with a `ZeroDivisionError`, reported in the chatter as an…
### Issue: Importing a UBL invoice containing a line with `LineExtensionAmount=0`, `InvoicedQuantity=0` and a non-zero `PriceAmount` failed with a `ZeroDivisionError`, reported in the chatter as an import error Such lines are valid UBL but carry no meaningful value, so they are silently skipped after the fix ### Cause: After this commit: https://github.com/odoo/odoo/commit/a7f77f3cfc42764328e7da73a60df8d4cafc968f The `line_extension_amount` was able to go in new parts of the code with a 0.0 value When `line_extension_amount` is set and `invoiced_quantity` is 0, `quantity` is computed as `subtotal * price_quantity / (...)` which resolves to 0 since `subtotal` is also 0 `price_unit = subtotal / quantity` then divides by zero ### Steps to reproduce: - Install `l10n_be` - Import a UBL invoice with a line where `LineExtensionAmount=0`, `InvoicedQuantity=0` and `PriceAmount` is non-zero (You can use the xml on the ticket) Before the fix, the import failed with an error in the chatter opw-6234453 Forward-Port-Of: odoo/odoo#271001
Outlook calendar synchronization now correctly recognizes attendees even when email capitalization differs. This prevents the same person from appearing twice on synced events, keeping meeting participant lists cleaner and more reliable.
Original PR description
In the Outlook calendar sync, it's possible to have the same attendee twice. That's because the normalized email wasn't used to check for preexisting attendee. To reproduce, sync event with the organizer, also an attendee, using high case in the email such as: ORGANIZER: Mike@organizer.com ATTENDEE: Mike@organizer.com ATTENDEE: John@attendee.com opw-6186606 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268201
Custom invoice report attachments now keep their configured report names when invoices are sent by email. This prevents localized invoice attachments from appearing as duplicates and makes it easier for users and customers to identify the right documents.
Original PR description
Steps to reproduce: * Install `l10n_mx_edi` (or `l10n_sa_edi`). * Go to **Accounting → Customers → Invoices**. * Open **Studio** and, from the top bar, go to **Reports**. * Duplicate the standard…
Steps to reproduce: * Install `l10n_mx_edi` (or `l10n_sa_edi`). * Go to **Accounting → Customers → Invoices**. * Open **Studio** and, from the top bar, go to **Reports**. * Duplicate the standard **Invoice PDF** report. * Open the duplicated report and make any modification to it. * Enable **Developer Mode**. * Go to **Settings → Technical → Actions → Reports** and update the custom report's **Printed Report Name**. * Go to **Settings → Technical → Email → Templates** and create a new invoice email template. * Add the custom report to the template's **Dynamic Reports**. * Create and confirm an invoice for a **Mexican company**. * Click **Send** and select the newly created email template. Observed behavior: * The custom report attachment uses the CFDI-based filename instead of its own report name, making it appear as a duplicate of the standard invoice attachment. Cause: * `_get_placeholder_mail_template_dynamic_attachments_data` relied on the `invoice_report` context key to pass the extra report into `_get_invoice_report_filename`. However, localization overrides (e.g. `l10n_mx_edi`, `l10n_sa_edi`) unconditionally return their own filename without checking the context, so the extra report's `print_report_name` was never evaluated. Fix: * Introduce `_get_invoice_mail_template_dynamic_report_filename` on `account.move` that directly evaluates a given report's `print_report_name`, bypassing the localization override chain. * Call this new method in `_get_placeholder_mail_template_dynamic_attachments_data` instead of the context-based `_get_invoice_report_filename` call. This avoids the need to patch every localization override and cleanly separates the concern of naming dynamic report attachments from the main invoice report filename logic. opw-6228268 Forward-Port-Of: odoo/odoo#271489
Project tasks marked as private are now prevented from being chosen as parent tasks. This helps keep private work from being exposed or linked in ways that could confuse task organization or visibility.
Original PR description
In this commit, we ensure that private tasks can never be selected as parent tasks. task-5119141 Forward-Port-Of: odoo/odoo#271824 Forward-Port-Of: odoo/odoo#270795
The German SKR03 accounting template now uses the correct default account codes for cash discounts. This helps companies using German localization record discounts in the proper accounts and reduces manual correction work.
Original PR description
The default cash discout accounts referenced in the
German skr03 template used the wrong account codes.
The template has been updated with the right ones.
task-4915939
opw-4909059
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#271383
Forward-Port-Of: odoo/odoo#271024A minor typo in the system's redirection logic for signatures has been corrected. This ensures users are correctly directed to the correct page for managing their signatures, improving the user experience. This fix prevents potential confusion and ensures proper functionality.
Original PR description
There was a typo when forward-porting PR 116949, the redirection should be /my/signatures instead of /my/signature/signatures.
This update resolves an issue where undoing a planning action incorrectly removed allocated hours. The fix creates the necessary planning role directly within the test environment, ensuring the undo operation functions as expected and maintains accurate time tracking. This improves the reliability of the planning module.
Original PR description
Fix by creating the planning role directly within the test, making it self-contained. runbot error-939985 Forward-Port-Of: odoo/enterprise#121111
This update fixes a display inconsistency in Helpdesk ticket views. Previously, list and form views showed the default state label instead of the updated one seen in the Kanban view. The fix removes outdated field references, ensuring all views now accurately reflect the selected state.
Original PR description
Steps to reproduce: ------------------------ 1. Install Helpdesk 2. Go to All Tickets and check the kanban state selection value 3. Go to Settings > Field Selection and search for kanban_state in…
Steps to reproduce:
------------------------
1. Install Helpdesk
2. Go to All Tickets and check the kanban state selection value
3. Go to Settings > Field Selection and search for kanban_state in `helpdesk.ticket` model
4. Change one of the state selection values (e.g., "Ready" to "Testing Ready")
5. Go back and check the state selection value in list and form views
Current behavior:
-----------------------
Kanban view correctly shows the updated label (e.g., "Testing Ready"),
but list and form views still display the old default value (e.g., "Ready").
Root cause:
---------------
The [state_selection](https://github.com/odoo/odoo/blob/c09cefdb0ed68b1b7367b77b18a5ee5d66c94900/addons/web/static/src/views/fields/state_selection/state_selection_field.js#L57-L65) widget uses `legend_${state}` field values when available.
Since list and form views included these legend fields, the widget resolved labels from them
instead of the actual selection values, causing inconsistent display.
Fix:
-----
Remove `legend_normal`, `legend_blocked`, and `legend_done` fields from the list and form views,
So the widget falls back to the real selection labels, consistent with how the kanban view behaves.
Reference commit: https://github.com/odoo/enterprise/commit/65f3b88254e3a66e2c5dcb5142d30f6b1996d999
opw-6238765
Forward-Port-Of: odoo/enterprise#119707