Odoo Changelog — 2026-03-07

Saturday, March 7, 2026

5 changes · saas-18.3

Bug Fixes(5)

Resolved issues and error corrections

[FIX] spreadsheet_edition: restrict 'Insert in spreadsheet' in list menu action

Enterprisesaas-18.3spreadsheet_edition

This update ensures that the 'Insert in spreadsheet' action is only visible to users with the necessary permissions for Documents and Dashboards. Previously, users without these permissions could still see the action, which has now been corrected for a more streamlined and secure user experience.

Original PR description

Current behavior before PR:
- The 'Insert in spreadsheet' action was always visible in the list view action menu, even when the user lacked access rights for Documents or Dashboards.

Desired behavior after PR is merged:
- The action is shown in the list view action menu only if the user has the required permissions.

Task: 5930184

Forward-Port-Of: odoo/enterprise#109739
Forward-Port-Of: odoo/enterprise#108099

#permissions#user experience#spreadsheet

[FIX] base_vat: ensure valid NRI GSTINs are accepted

PR #252644

Coresaas-18.3base_vat

This update fixes an issue where the system incorrectly rejected valid Non-Resident Indian (NRI) GSTINs. The change adjusts the validation process to accept a wider range of valid GSTIN formats, ensuring accurate tax ID input for NRI company records. This prevents errors and improves data integrity.

Original PR description

Currently, valid GSTINs for certain Non-Resident taxpayers are rejected. **Steps to reproduce:** - Install the `l10n_in` module. - Navigate to Settings > Users & Companies > Companies. - Open `IN…

Currently, valid GSTINs for certain Non-Resident taxpayers are rejected.

**Steps to reproduce:**
- Install the `l10n_in` module.
- Navigate to Settings > Users & Companies > Companies.
- Open `IN Company` and set `Tax ID` to `9922JPN29001OSU` and try to `save`.

**Error:**
`The VAT number [9922JPN29001OSU] for partner [IN Company] does not seem to be valid.` 
`Note: the expected format is 12AAAAA1234AAZA`

The system rejects the GSTIN, although it is valid and verifiable on the 
official GST portal: https://services.gst.gov.in/services/searchtp

**Root cause:**
At [2], the GSTIN validation regex for NRI taxpayers only supports formats 
ending with `NRX` (X = any alphanumeric character). However, certain valid 
GSTINs follow a different structure and are not matched by the existing regex.

**Fix:**
This commit ensures that valid NRI GSTIN formats are accepted during validation.

Confirm with IN PO.

[1]:
https://services.gst.gov.in/services/searchtp

[2]:
https://github.com/odoo/odoo/blob/5e59f4b3def44aa84c06ba4c2ed34bf2e8da928f/addons/base_vat/models/res_partner.py#L712-L723

opw-5956299

Forward-Port-Of: odoo/odoo#252540
Forward-Port-Of: odoo/odoo#251760

#gstin#tax# NRI

[FIX] l10n_co_dian: prevent crash when printing duplicated support document

PR #109877

Enterprisesaas-18.3l10n_co_dian

This update resolves a printing error that occurred when generating invoices with DIAN support documents. The fix prevents a crash caused by an attempt to print sections of the invoice when the necessary DIAN attachment wasn't available. This ensures invoices with multiple support documents can be printed correctly.

Original PR description

**Steps to reproduce:**
* Install the **l10n_co_dian** module.
* Enable DIAN 2.1 operation mode: **Support Documents** in settings.
* Create a vendor bill using a **DIAN support document** journal.
* Confirm the vendor bill.
* Click **Print**.

**Observed behavior:**
* Printing fails with `ValueError: can only parse strings`.

**Cause:**
* The report template unconditionally called `_l10n_co_dian_get_extra_invoice_report_values()`, which parses `l10n_co_dian_attachment_id.raw` via `etree.fromstring()`.
* On duplicated bills, `l10n_co_dian_document_ids` (and thus the computed `l10n_co_dian_attachment_id`) is empty, so `.raw` is `False`.

**Fix:**
* Wrap the QR code / CUFE / signing section in the report template with `t-if='o.l10n_co_dian_attachment_id'` so it is only rendered when the DIAN attachment exists.

opw-5930173

Forward-Port-Of: odoo/enterprise#108645

#DIAN#support documents#printing

[FIX] spreadsheet_edition: allow kanban insertion with m2m group and fix permissions

PR #109867

Enterprisesaas-18.3spreadsheet_editionMEDIUM

This update fixes a previous issue where users without proper permissions could access the 'Insert in spreadsheet' action in Kanban views. Now, the action is only visible to users with the necessary permissions, and the restriction on inserting records based on grouped m2m fields has been removed, streamlining the process of adding data from Kanban to spreadsheets.

Original PR description

Current behavior before PR:
- The 'Insert in spreadsheet' action was always visible in the kanban view action menu, even when the user lacked access rights for Documents or Dashboards.
- Inserting records from a kanban view into a spreadsheet was blocked when the view was grouped by an m2m field.

Desired behavior after PR is merged:
- The action is shown in the kanban view action menu only if the user has the required permissions.
- The m2m field check is removed when inserting from kanban views.

Task: 5930184

Forward-Port-Of: odoo/enterprise#108098

#spreadsheet#kanban#permissions

[FIX] mrp: use work center availability to compute total expected workorder duration

PR #250228

Coresaas-18.3mrpMEDIUM

This update fixes an issue where manufacturing order end dates were incorrectly calculated, assuming work centers operated 24/7. The change now accurately considers work center availability, ensuring more precise scheduling and reducing potential delays in production. This improves the reliability of production planning.

Original PR description

**Issue**
The scheduled end date of a manufacturing order incorrectly assumes that the work center operates 24 hours a day.

**Steps to reproduce**
1. Create a manufacturing order with:
   - A work order with an expected duration of 1440 minutes.
   - A work center configured to work 8 hours per day.
2. Observe that the scheduled end date is computed as if the work center operates 24h/day resulting in an end date 1 day instead of 4 after the starting date.

**Cause**
The `date_finish` computation:
https://github.com/odoo/odoo/blob/680085b55728dcb000e7bb4277bb83b0e4e2ce91/addons/mrp/models/mrp_production.py#L745C1-L746C105
does not take into account neither the work center’s calendar nor the workorder dependency when estimating the duration.

**Solution**
Use `_get_first_available_slot`:
https://github.com/odoo/odoo/blob/5d75037d4f81d71a50394c3d390c420967766731/addons/mrp/models/mrp_workcenter.py#L332
to consider workcenter availability, inspired from when a workorder is planned:
https://github.com/odoo/odoo/blob/5d75037d4f81d71a50394c3d390c420967766731/addons/mrp/models/mrp_workorder.py#L527
**Additionnal notes**
- If a workcenter of at least one workorder is unavailable, just fallback on the previous computation.
- The solution does not take workorder dependencies into account due to related technical limitation see https://github.com/odoo/odoo/pull/232805 for an earlier attempt to handle dependencies.
- Our test rely on the assertAlmostEqual for the same reason than https://github.com/odoo/odoo/commit/e6c958ca226bd8ef7e518243c93e40b92b9b5919

opw-[5084120](https://www.odoo.com/web#id=5084120&view_type=form&model=project.task)

Forward-Port-Of: odoo/odoo#240617

#manufacturing#production#scheduling

Current behavior before PR: - The 'Insert in spreadsheet' action was always visible in the list view action menu, even when the user lacked access rights for Documents or Dashboards. Desired behavior after PR is merged: - The action is shown in the list view action menu only if the user has the required permissions. Task: 5930184 Forward-Port-Of: odoo/enterprise#109739 Forward-Port-Of: odoo/enterprise#108099

Currently, valid GSTINs for certain Non-Resident taxpayers are rejected. **Steps to reproduce:** - Install the `l10n_in` module. - Navigate to Settings > Users & Companies > Companies. - Open `IN Company` and set `Tax ID` to `9922JPN29001OSU` and try to `save`. **Error:** `The VAT number [9922JPN29001OSU] for partner [IN Company] does not seem to be valid.` `Note: the expected format is 12AAAAA1234AAZA` The system rejects the GSTIN, although it is valid and verifiable on the official GST portal: https://services.gst.gov.in/services/searchtp **Root cause:** At [2], the GSTIN validation regex for NRI taxpayers only supports formats ending with `NRX` (X = any alphanumeric character). However, certain valid GSTINs follow a different structure and are not matched by the existing regex. **Fix:** This commit ensures that valid NRI GSTIN formats are accepted during validation. Confirm with IN PO. [1]: https://services.gst.gov.in/services/searchtp [2]: https://github.com/odoo/odoo/blob/5e59f4b3def44aa84c06ba4c2ed34bf2e8da928f/addons/base_vat/models/res_partner.py#L712-L723 opw-5956299 Forward-Port-Of: odoo/odoo#252540 Forward-Port-Of: odoo/odoo#251760

**Steps to reproduce:** * Install the **l10n_co_dian** module. * Enable DIAN 2.1 operation mode: **Support Documents** in settings. * Create a vendor bill using a **DIAN support document** journal. * Confirm the vendor bill. * Click **Print**. **Observed behavior:** * Printing fails with `ValueError: can only parse strings`. **Cause:** * The report template unconditionally called `_l10n_co_dian_get_extra_invoice_report_values()`, which parses `l10n_co_dian_attachment_id.raw` via `etree.fromstring()`. * On duplicated bills, `l10n_co_dian_document_ids` (and thus the computed `l10n_co_dian_attachment_id`) is empty, so `.raw` is `False`. **Fix:** * Wrap the QR code / CUFE / signing section in the report template with `t-if='o.l10n_co_dian_attachment_id'` so it is only rendered when the DIAN attachment exists. opw-5930173 Forward-Port-Of: odoo/enterprise#108645

Current behavior before PR: - The 'Insert in spreadsheet' action was always visible in the kanban view action menu, even when the user lacked access rights for Documents or Dashboards. - Inserting records from a kanban view into a spreadsheet was blocked when the view was grouped by an m2m field. Desired behavior after PR is merged: - The action is shown in the kanban view action menu only if the user has the required permissions. - The m2m field check is removed when inserting from kanban views. Task: 5930184 Forward-Port-Of: odoo/enterprise#108098

**Issue** The scheduled end date of a manufacturing order incorrectly assumes that the work center operates 24 hours a day. **Steps to reproduce** 1. Create a manufacturing order with: - A work order with an expected duration of 1440 minutes. - A work center configured to work 8 hours per day. 2. Observe that the scheduled end date is computed as if the work center operates 24h/day resulting in an end date 1 day instead of 4 after the starting date. **Cause** The `date_finish` computation: https://github.com/odoo/odoo/blob/680085b55728dcb000e7bb4277bb83b0e4e2ce91/addons/mrp/models/mrp_production.py#L745C1-L746C105 does not take into account neither the work center’s calendar nor the workorder dependency when estimating the duration. **Solution** Use `_get_first_available_slot`: https://github.com/odoo/odoo/blob/5d75037d4f81d71a50394c3d390c420967766731/addons/mrp/models/mrp_workcenter.py#L332 to consider workcenter availability, inspired from when a workorder is planned: https://github.com/odoo/odoo/blob/5d75037d4f81d71a50394c3d390c420967766731/addons/mrp/models/mrp_workorder.py#L527 **Additionnal notes** - If a workcenter of at least one workorder is unavailable, just fallback on the previous computation. - The solution does not take workorder dependencies into account due to related technical limitation see https://github.com/odoo/odoo/pull/232805 for an earlier attempt to handle dependencies. - Our test rely on the assertAlmostEqual for the same reason than https://github.com/odoo/odoo/commit/e6c958ca226bd8ef7e518243c93e40b92b9b5919 opw-[5084120](https://www.odoo.com/web#id=5084120&view_type=form&model=project.task) Forward-Port-Of: odoo/odoo#240617