Odoo Changelog — 2026-06-27

Saturday, June 27, 2026

9 changes · saas-19.2

Bug Fixes(9)

Resolved issues and error corrections

[FIX] mrp_workorder: sort unplanned MOs last in shop floor

Enterprisesaas-19.2mrp_workorderMEDIUM

Shop Floor now sorts manufacturing orders more consistently by putting unplanned work orders after planned ones. This fixes a display issue where orders without a scheduled start date could incorrectly appear ahead of orders that were already planned, making priorities clearer for operators.

Original PR description

## Problem In shop floor, MOs with unplanned work orders get sorted before MOs that have planned operations, which contradicts the normal nulls last sorting for work orders. ## Solution We will…

## Problem
In shop floor, MOs with unplanned work orders get sorted before MOs that have planned operations, which contradicts the normal nulls last sorting for work orders.

## Solution
We will update the sorting logic in the MrpDisplay component to more gracefully handle falsy date_start values, sorting them to the end.

## Steps to reproduce (runbot 19)
1. Create 2 MOs with an operation (work order) involving a work center, we'll call them A and B.
2. Open Shop Floor and open the work center that the MOs' work orders belong to, and note they are ordered A, B (this is fine, neither are planned so the precedence falls back to id
3. Go back to MO B and plan it. This should give it precedence in Shop Floor
4. Under the work center in Shop Floor, note that the MOs are still ordered A, B, despite B's work order having a start date and A's work order not having one

To further motivate this being unintended, you can go to Manufacturing > Operations > Work Orders, and you'll see MO B's work order sitting at the top of the list.

opw-6303323

Forward-Port-Of: odoo/enterprise#121693

#shop floor#manufacturing orders#work orders#sorting#planning

[FIX] html_editor: prevent cursor snapping in <t> block

PR #272285

Coresaas-19.2html_editorMEDIUM

This change fixes an editor issue where the cursor could jump to the edge of a template block when deleting text inside it. Editing email templates is now smoother and more predictable, reducing the chance of losing your place while making small changes.

Original PR description

## Problem:
`<t>` elements are classified as self-closing, even if they aren't used that way in a mail template. If you press backspace in the editor on some plain text that happens to be inside a `<t></t>` block, the editor would prevent the cursor from being placed back inside the block after merging because of `normalizeSelfClosingElement`. The result is the cursor being left on the outside edge of the block.

## Solution:
We will remove "T" from the list of self-closing tags.

## Steps to replicate (runbot v18):
1. Open an email template (Purchase: Purchase Order)
2. Place your cursor in some text inside a t-if element ('The receipt is expected for...'). Press backspace. Your cursor will snap to the end of the t-if block.

opw-6124284

Forward-Port-Of: odoo/odoo#266816

#editor#email templates#cursor#usability

[FIX] sale_timesheet_enterprise_holidays: fix traceback opening billing target

PR #121888

Enterprisesaas-19.2sale_timesheet_enterprise_holidaysMEDIUM

This fix prevents a traceback when users open a Billing Time Target from Timesheets. It restores the expected screen flow so users can review billing targets without interruption.

Original PR description

Prerequisites to reproduce:
- Enable `Billing Rate Indicators` in timesheets.
- Change timesheet access of user to  `User: all timesheets`
- Remove Employee access

Steps to Reproduce:

- In Timesheets app, from configuration go to `Billing Time Targets`
- Click on view button on any row

Issue:

- A traceback breaking the flow.

Reason:

- We use `hr_presence_status` widget which requires `leave_date_to`   field, change made from odoo/odoo@0496ed1 and https://github.com/odoo/odoo/commit/4b5089694436aa00254666e10cd2106b21adfe2b 
- Thus unavailability of field causing the traceback.

Fix:

- Add a related field for leave_date_to from which we get the value.

Forward-Port-Of: odoo/enterprise#121571

#timesheets#billing#error fix#ui

[FIX] l10n_co_dian: clear BuyerReference for debit notes

PR #121860

Enterprisesaas-19.2l10n_co_dianMEDIUM

This update prevents an error when sending Colombian debit notes to DIAN. The system now leaves out an unnecessary reference field for this document type, so debit notes can be generated and submitted successfully.

Original PR description

Issue:
Sending Debit Notes to a tax authority can cause the following error: "ValueError: The following child node is not defined in the template: DebitNote/cbc:BuyerReference"

Steps to reproduce on any database with DIAN and Colombian localization:

  1. Create a new "Sales" type journal. Then, check the checkbox “Nota de Debito”.
  2. Find a res.partner with a ref field, or add a ref field to any partner.
  3. Make an invoice using the partner found in step 2. Ensure it uses a tax. Confirm it.
  4. Send that invoice to DIAN.
  5. Create a Debit Note for that invoice. Use the journal created in step 1.
  6. Add a product, price, and tax to the debit note. Confirm it.
  7. Send the debit note to DIAN.
  
Explanation:
The `_add_invoice_header_nodes` method on the AccountEdiXmlUbl_21 model adds a BuyerReference node unconditionally. (See account_edi_xml_ubl_21.py.) But the DebitNote XML template does not include a BuyerReference element (see ubl_21_debit_note.py). This caused a ValueError when assembling the XML for debit note documents.

Solution: The fix overrides this in the Colombian localization by clearing the BuyerReference value when the document type is "debit_note". That way, the node is omitted from the output.

opw-6181039

Forward-Port-Of: odoo/enterprise#121458
Forward-Port-Of: odoo/enterprise#121422

#colombia#dian#debit note#e-invoicing

[FIX] l10n_co_dian: update translations of DIAN email templates

PR #121953

Enterprisesaas-19.2l10n_co_dianMEDIUM

When a new language is added, the DIAN email templates will now also appear translated instead of staying in the original language. This improves the user experience for Colombian businesses using DIAN documents, especially for teams working in multiple languages.

Original PR description

### Issue: When installing a new language on a database with `l10n_co_dian`, the DIAN email templates are not translated Languages already installed when `l10n_co_dian` is installed are correctly…

### Issue:
When installing a new language on a database with `l10n_co_dian`, the DIAN email templates are not translated

Languages already installed when `l10n_co_dian` is installed are correctly translated, as the copy happens at that moment
Only languages installed afterwards are affected

### Cause:
The DIAN email templates are created dynamically via `_create_dian_mail_templates` as copies of the `account` templates
Because they are created at runtime, no translations exist for their XML IDs in the `l10n_co_dian` `.po` files
The `TranslationImporter` finds nothing to import for them

The fix hooks into `_load_module_terms` to sync translations from the source `account` templates to the DIAN ones whenever a new language is installed

`TranslationImporter.save()` is used without `force_overwrite`, so existing translations on `noupdate` records are never replaced
This is the standard way to push translations while preserving any manually modified values

### Notes:
Languages installed before this fix are not updated
Only newly installed languages will get the synced translations

### Steps to reproduce:
- Install `l10n_co_dian`
- Enable Developer Mode in Settings
- Install any language (e.g. `fr_FR`)
- Go in Settings > Technical > Email > Email Templates
- Search for DIAN and open Invoice or Credit Note

Before the fix, the DIAN invoice and credit note templates had untranslated name, description and body_html

opw-6269979

Forward-Port-Of: odoo/enterprise#120855

#translations#email templates#DIAN#Colombia#localization

[FIX] databases: synchronize databases access error

PR #121974

Enterprisesaas-19.2databasesMEDIUM

This update fixes an access problem that could block database users from syncing their databases. It ensures the right permission check is applied so the process continues without unnecessary errors.

Original PR description

The aim of this commit is to allow the databases_user to synchronize their databases.

Context:
The commit https://github.com/odoo/odoo/commit/846eb51a02baaf2e4f6e6780f8d0ceb23322c38b introduced a change of behavior in stable that performs some more check on access rights.

Before this commit:
The checks introduced by the commit resulted in an access error. There wasn't any groups on the action itself resulting in a check of the access right "write" on the model.
As the model is `project.project` and a databases_user might not be granted write access on the project itself, it resulted in an access error.

After this commit:
The flow continues smoothly.
As the action has now a group set on it, this is checked first and match the proper access right.

opw-6329058

Forward-Port-Of: odoo/enterprise#121589

#access rights#database sync#bug fix

[FIX] pos_cashmatic: amount send to the Cashmatic machine

PR #272627

Coresaas-19.2pos_cashmaticMEDIUM

This update makes sure amounts sent to Cashmatic cash machines are calculated in the fixed format they actually support. It prevents incorrect payment values when different currencies are used, including the special case of Chilean Peso.

Original PR description

Despite its API description, the Cashmatic machine always operates with 2 decimal places regardless of the currency. According to the Cashmatic head developer, only 2-decimal currencies are supported, with the sole exception of Chilean Peso (CLP) which has no decimals but is still handled with a fixed 100 cents-per-unit factor.

Replace `Math.pow(10, currency.decimal_places)` with a `CENTS_PER_UNIT` constant set to 100 to make this assumption explicit.

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#272465

#point of sale#payments#currency#cash management

[FIX] sale_subscription: no RR calc for non recurring products

PR #121681

Enterprisesaas-19.2sale_subscriptionMEDIUM

Subscription reports now ignore non-recurring products when calculating monthly and yearly recurring revenue. This prevents MRR and YRR totals from being overstated if users remove the default recurring-only filter in the report.

Original PR description

While investigating a support ticket, we noticed that in subscription reports, recurring revenue values (MRR and YRR) are implicitly calculated for non-recurring products.

This doesn't cause a direct problem when using the default search domains applied in Subscription > Reporting > Subscription > Pivot view, because a "Recurring" filter is pre-applied. But if the end user removes said filter, they might accidentally fudge the MRR and YRR numbers because the non-recurring products will contributed to the relevant grouping sums.

We fix this by adding a CASE clause to explicitly ignore non-recurring products when calculating the report field for MRR and YRR , i.e. only consider `t.recurring_invoice = TRUE`.

OPW-6315091

Forward-Port-Of: odoo/enterprise#121566

#subscription#reporting#MRR#YRR#revenue#filters

[FIX] website: fix clickable carousel slide tour

PR #272623

Coresaas-19.2website

This update makes the website carousel editing test more reliable by using a direct, consistent way to confirm the edited link. It reduces the chance of the tour failing randomly, which helps keep website updates and automated checks stable.

Original PR description

Make the step deterministic by committing the URL with edit and
pressing Tab in the input instead of relying on a dropdown click.

runbot-241089

Forward-Port-Of: odoo/odoo#272374

#tests#website#carousel#stability

## Problem In shop floor, MOs with unplanned work orders get sorted before MOs that have planned operations, which contradicts the normal nulls last sorting for work orders. ## Solution We will update the sorting logic in the MrpDisplay component to more gracefully handle falsy date_start values, sorting them to the end. ## Steps to reproduce (runbot 19) 1. Create 2 MOs with an operation (work order) involving a work center, we'll call them A and B. 2. Open Shop Floor and open the work center that the MOs' work orders belong to, and note they are ordered A, B (this is fine, neither are planned so the precedence falls back to id 3. Go back to MO B and plan it. This should give it precedence in Shop Floor 4. Under the work center in Shop Floor, note that the MOs are still ordered A, B, despite B's work order having a start date and A's work order not having one To further motivate this being unintended, you can go to Manufacturing > Operations > Work Orders, and you'll see MO B's work order sitting at the top of the list. opw-6303323 Forward-Port-Of: odoo/enterprise#121693

## Problem: `<t>` elements are classified as self-closing, even if they aren't used that way in a mail template. If you press backspace in the editor on some plain text that happens to be inside a `<t></t>` block, the editor would prevent the cursor from being placed back inside the block after merging because of `normalizeSelfClosingElement`. The result is the cursor being left on the outside edge of the block. ## Solution: We will remove "T" from the list of self-closing tags. ## Steps to replicate (runbot v18): 1. Open an email template (Purchase: Purchase Order) 2. Place your cursor in some text inside a t-if element ('The receipt is expected for...'). Press backspace. Your cursor will snap to the end of the t-if block. opw-6124284 Forward-Port-Of: odoo/odoo#266816

Prerequisites to reproduce: - Enable `Billing Rate Indicators` in timesheets. - Change timesheet access of user to `User: all timesheets` - Remove Employee access Steps to Reproduce: - In Timesheets app, from configuration go to `Billing Time Targets` - Click on view button on any row Issue: - A traceback breaking the flow. Reason: - We use `hr_presence_status` widget which requires `leave_date_to` field, change made from odoo/odoo@0496ed1 and https://github.com/odoo/odoo/commit/4b5089694436aa00254666e10cd2106b21adfe2b - Thus unavailability of field causing the traceback. Fix: - Add a related field for leave_date_to from which we get the value. Forward-Port-Of: odoo/enterprise#121571

Issue: Sending Debit Notes to a tax authority can cause the following error: "ValueError: The following child node is not defined in the template: DebitNote/cbc:BuyerReference" Steps to reproduce on any database with DIAN and Colombian localization: 1. Create a new "Sales" type journal. Then, check the checkbox “Nota de Debito”. 2. Find a res.partner with a ref field, or add a ref field to any partner. 3. Make an invoice using the partner found in step 2. Ensure it uses a tax. Confirm it. 4. Send that invoice to DIAN. 5. Create a Debit Note for that invoice. Use the journal created in step 1. 6. Add a product, price, and tax to the debit note. Confirm it. 7. Send the debit note to DIAN. Explanation: The `_add_invoice_header_nodes` method on the AccountEdiXmlUbl_21 model adds a BuyerReference node unconditionally. (See account_edi_xml_ubl_21.py.) But the DebitNote XML template does not include a BuyerReference element (see ubl_21_debit_note.py). This caused a ValueError when assembling the XML for debit note documents. Solution: The fix overrides this in the Colombian localization by clearing the BuyerReference value when the document type is "debit_note". That way, the node is omitted from the output. opw-6181039 Forward-Port-Of: odoo/enterprise#121458 Forward-Port-Of: odoo/enterprise#121422

### Issue: When installing a new language on a database with `l10n_co_dian`, the DIAN email templates are not translated Languages already installed when `l10n_co_dian` is installed are correctly translated, as the copy happens at that moment Only languages installed afterwards are affected ### Cause: The DIAN email templates are created dynamically via `_create_dian_mail_templates` as copies of the `account` templates Because they are created at runtime, no translations exist for their XML IDs in the `l10n_co_dian` `.po` files The `TranslationImporter` finds nothing to import for them The fix hooks into `_load_module_terms` to sync translations from the source `account` templates to the DIAN ones whenever a new language is installed `TranslationImporter.save()` is used without `force_overwrite`, so existing translations on `noupdate` records are never replaced This is the standard way to push translations while preserving any manually modified values ### Notes: Languages installed before this fix are not updated Only newly installed languages will get the synced translations ### Steps to reproduce: - Install `l10n_co_dian` - Enable Developer Mode in Settings - Install any language (e.g. `fr_FR`) - Go in Settings > Technical > Email > Email Templates - Search for DIAN and open Invoice or Credit Note Before the fix, the DIAN invoice and credit note templates had untranslated name, description and body_html opw-6269979 Forward-Port-Of: odoo/enterprise#120855

The aim of this commit is to allow the databases_user to synchronize their databases. Context: The commit https://github.com/odoo/odoo/commit/846eb51a02baaf2e4f6e6780f8d0ceb23322c38b introduced a change of behavior in stable that performs some more check on access rights. Before this commit: The checks introduced by the commit resulted in an access error. There wasn't any groups on the action itself resulting in a check of the access right "write" on the model. As the model is `project.project` and a databases_user might not be granted write access on the project itself, it resulted in an access error. After this commit: The flow continues smoothly. As the action has now a group set on it, this is checked first and match the proper access right. opw-6329058 Forward-Port-Of: odoo/enterprise#121589

Despite its API description, the Cashmatic machine always operates with 2 decimal places regardless of the currency. According to the Cashmatic head developer, only 2-decimal currencies are supported, with the sole exception of Chilean Peso (CLP) which has no decimals but is still handled with a fixed 100 cents-per-unit factor. Replace `Math.pow(10, currency.decimal_places)` with a `CENTS_PER_UNIT` constant set to 100 to make this assumption explicit. 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#272465

While investigating a support ticket, we noticed that in subscription reports, recurring revenue values (MRR and YRR) are implicitly calculated for non-recurring products. This doesn't cause a direct problem when using the default search domains applied in Subscription > Reporting > Subscription > Pivot view, because a "Recurring" filter is pre-applied. But if the end user removes said filter, they might accidentally fudge the MRR and YRR numbers because the non-recurring products will contributed to the relevant grouping sums. We fix this by adding a CASE clause to explicitly ignore non-recurring products when calculating the report field for MRR and YRR , i.e. only consider `t.recurring_invoice = TRUE`. OPW-6315091 Forward-Port-Of: odoo/enterprise#121566