Odoo Changelog — 2026-09-21

Monday, September 21, 2026

4 changes · saas-19.4

Improvements(4)

Enhancements to existing features

[PERF] l10n_co_edi: avoid stored field computation during installation

PR #131963

Enterprisesaas-19.4l10n_co_ediMedium

Installing the Colombian electronic invoicing module is now faster and more reliable on large databases. Existing accounting records no longer need time-consuming recalculations during setup, reducing the risk of installation timeouts while keeping future invoice behavior unchanged.

Original PR description

- Use the `init_storage` field attribute to initialize the stored computed column `l10n_co_edi_cufe_cude_ref`, `l10n_co_edi_state`, `l10n_co_edi_operation_type`, `l10n_co_edi_commercial_state`…

- Use the `init_storage` field attribute to initialize the stored computed
  column `l10n_co_edi_cufe_cude_ref`, `l10n_co_edi_state`,
  `l10n_co_edi_operation_type`, `l10n_co_edi_commercial_state` directly in
  the database.

- This prevents Odoo from computing and writing the field for all existing
  `account.move` records when installing `l10n_co_edi`.

- This is particularly important for large databases with a high volume of
  Colombian accounting moves, where the initial computation can take too long
  and cause the module installation to hit the time limit.

- Keep the compute method unchanged so the field continues to be computed
  normally for subsequent record creation or dependency changes.

- Remove the `default` from `l10n_co_edi_commercial_state` since the
  `default` sets the field to `pending` while the compute sets it to
  `False` when no accepted EDI document exists. Move `pending` to
  `default_get` to preserve the current behavior while keeping the
  initialization consistent with the compute.

**opw-6451331**

#performance#installation#colombia#edi

[IMP] website_sale: allow donation products to be archived

PR #289463

Coresaas-19.4website_saleMedium

Merchants can now archive donation products when they stop using the donation snippet, instead of being blocked by an error. Archived donation products stay unavailable to shoppers and the donation snippet shows that the product was not found, while deletion remains restricted to protect existing records.

Original PR description

Before: archiving the donation product raised a ValidationError (Sales > Products > Donation > Action > Archive), with no way to hide it once a merchant stopped using the donation snippet. Deletion stays blocked.

After: archiving works. `_is_add_to_cart_allowed()` now checks `active` before the donation bypass, and `/shop/donation/info` returns nothing for an archived donation product, so the snippet reports "Donation product not found" instead of using a hidden one.

opw-6574867

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#donations#products#archive#ecommerce

[IMP] l10n_ro_edi_stock: support dropship operations

PR #289503

Coresaas-19.4l10n_ro_edi_stockMedium

Romanian eTransport declarations can now be generated for supported dropshipping sales, covering domestic and international B2C scenarios. This helps businesses using dropship workflows stay compliant with Romanian transport reporting requirements, while unsupported B2B dropship cases now show clear errors.

Original PR description

Before this commit:
Dropship operations were not supported by the Romanian eTransport integration. As a result, eTransport declarations could not be generated for dropshipping flows.

After this commit:
eTransport declarations can now be generated for dropship operations, allowing the supported dropshipping scenarios to be processed through the Romanian eTransport workflow.

task-6391489

Forward-Port-Of: odoo/odoo#289344
Forward-Port-Of: odoo/odoo#280199

#Romania#eTransport#dropshipping#compliance

[PERF] stock_account: reduce search calls in _get_value_data()

PR #278302

Coresaas-19.4stock_accountMedium

Improves performance when calculating average inventory costs for dropshipped products by avoiding unnecessary record lookups. This can significantly reduce processing time for large stock batches where most movements do not need manual valuation data.

Original PR description

During the _run_average_batch(), we call _get_value() on each dropship move on which an AVCO product is used. In this function, if the following condition is met, we call the function…

During the _run_average_batch(), we call _get_value() on each dropship move on which an AVCO product is used. In this function, if the following condition is met, we call the function _get_manual_value():

https://github.com/odoo/odoo/blob/12dd03fb678870ddd3f1f8dca66aa3f934aa7985/addons/stock_account/models/stock_move.py#L359-L361

This method's goal is to search product.value records related to the current move.

https://github.com/odoo/odoo/blob/12dd03fb678870ddd3f1f8dca66aa3f934aa7985/addons/stock_account/models/stock_move.py#L431-L447

This search is performed once per move selected previously even if they are not related to any product.value.

We propose to cache the id of every move that is linked to at least one product.value to ensure the search method is only performed for those and potentially reduce the number of calls to the search method.

Benchmark
------------

Reducing the execution time with this modification supposes that the majority of stock.move records are not linked to any product.value, which is usually the case.
The following benchmark shows the execution times of _run_average_batch() depending on that.

| No stock.move | No of moves linked to product.value | Before PR | After PR |
|---------------|-------------------------------------|-----------|----------|
|           100 |                                  10 |    1.03 s |   421 ms |
|          1000 |                                 100 |    7.13 s |   1.14 s |
|         10000 |                                 100 |   57.21 s |   1.55 s |
|         10000 |                                1000 |   60.42 s |   8.98 s |

When every stock.move is linked to a product.value, the modification will introduce more operations than needed and slow down the execution. The following benchmark illustrates that.

| No stock.move | Before PR | After PR |
|---------------|-----------|----------|
|           100 |    1.14 s |   1.15 s |
|          1000 |    8.21 s |   8.37 s |
|         10000 |   80.64 s |  81.51 s |

opw-6050007

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#274850
Forward-Port-Of: odoo/odoo#257619

- Use the `init_storage` field attribute to initialize the stored computed column `l10n_co_edi_cufe_cude_ref`, `l10n_co_edi_state`, `l10n_co_edi_operation_type`, `l10n_co_edi_commercial_state` directly in the database. - This prevents Odoo from computing and writing the field for all existing `account.move` records when installing `l10n_co_edi`. - This is particularly important for large databases with a high volume of Colombian accounting moves, where the initial computation can take too long and cause the module installation to hit the time limit. - Keep the compute method unchanged so the field continues to be computed normally for subsequent record creation or dependency changes. - Remove the `default` from `l10n_co_edi_commercial_state` since the `default` sets the field to `pending` while the compute sets it to `False` when no accepted EDI document exists. Move `pending` to `default_get` to preserve the current behavior while keeping the initialization consistent with the compute. **opw-6451331**

Before: archiving the donation product raised a ValidationError (Sales > Products > Donation > Action > Archive), with no way to hide it once a merchant stopped using the donation snippet. Deletion stays blocked. After: archiving works. `_is_add_to_cart_allowed()` now checks `active` before the donation bypass, and `/shop/donation/info` returns nothing for an archived donation product, so the snippet reports "Donation product not found" instead of using a hidden one. opw-6574867 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Before this commit: Dropship operations were not supported by the Romanian eTransport integration. As a result, eTransport declarations could not be generated for dropshipping flows. After this commit: eTransport declarations can now be generated for dropship operations, allowing the supported dropshipping scenarios to be processed through the Romanian eTransport workflow. task-6391489 Forward-Port-Of: odoo/odoo#289344 Forward-Port-Of: odoo/odoo#280199

During the _run_average_batch(), we call _get_value() on each dropship move on which an AVCO product is used. In this function, if the following condition is met, we call the function _get_manual_value(): https://github.com/odoo/odoo/blob/12dd03fb678870ddd3f1f8dca66aa3f934aa7985/addons/stock_account/models/stock_move.py#L359-L361 This method's goal is to search product.value records related to the current move. https://github.com/odoo/odoo/blob/12dd03fb678870ddd3f1f8dca66aa3f934aa7985/addons/stock_account/models/stock_move.py#L431-L447 This search is performed once per move selected previously even if they are not related to any product.value. We propose to cache the id of every move that is linked to at least one product.value to ensure the search method is only performed for those and potentially reduce the number of calls to the search method. Benchmark ------------ Reducing the execution time with this modification supposes that the majority of stock.move records are not linked to any product.value, which is usually the case. The following benchmark shows the execution times of _run_average_batch() depending on that. | No stock.move | No of moves linked to product.value | Before PR | After PR | |---------------|-------------------------------------|-----------|----------| | 100 | 10 | 1.03 s | 421 ms | | 1000 | 100 | 7.13 s | 1.14 s | | 10000 | 100 | 57.21 s | 1.55 s | | 10000 | 1000 | 60.42 s | 8.98 s | When every stock.move is linked to a product.value, the modification will introduce more operations than needed and slow down the execution. The following benchmark illustrates that. | No stock.move | Before PR | After PR | |---------------|-----------|----------| | 100 | 1.14 s | 1.15 s | | 1000 | 8.21 s | 8.37 s | | 10000 | 80.64 s | 81.51 s | opw-6050007 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#274850 Forward-Port-Of: odoo/odoo#257619