Odoo Changelog — 2026-05-25

Monday, May 25, 2026

7 changes · saas-19.1

Bug Fixes(7)

Resolved issues and error corrections

[FIX] stock: ensure packaging unit and qty are shown for validated transfers.

Coresaas-19.1stockMEDIUM

This update fixes an issue where packaging unit information was missing from delivery slip reports after a transfer was validated. The change ensures that the correct packaging unit and quantity are displayed, providing more accurate tracking of products with packaging units. This improves inventory visibility and reporting accuracy.

Original PR description

Issue before this commit: ========================= For products tracked by serial/lot with packaging units, the delivery slip correctly shows the packaging unit and quantity before validating the…

Issue before this commit:
=========================
For products tracked by serial/lot with packaging units, the delivery slip correctly shows the packaging unit and quantity before validating the transfer. However, after validating the transfer, the packaging unit and its corresponding quantity are no longer displayed in the delivery slip report.

Steps to Reproduce:
=========================
1. Install stock and sale_management modules.
2. Enable Units of Measure & Packagings and Display Lots & Serial Numbers on Delivery Slips from settings.
3. Create a product with tracking by lot/serial number and configure a packaging unit.
4. Create a SO using this product with a packaging unit and confirm it.
5. Open the related transfer and print the delivery slip before and after validation.

Cause of the Issue:
=========================
The delivery slip report template (stock_report_delivery_has_serial_move_line) does not display packaging unit information after validation for move lines when the packaging unit differs from the product unit of measure.

With This Commit:
=========================
This commit ensures that packaging units and their corresponding quantities are displayed on the delivery slip after validation when the packaging unit differs from the product unit of measure.

Steps To Reporduce: [Video Link](https://drive.google.com/file/d/10DmFKW1Y_Tm-AyKzPrqtFMY8orBkKbIm/view?usp=sharing)

opw-6142052

Forward-Port-Of: odoo/odoo#265206

#inventory#packaging#delivery slips

[FIX] pos*: sync cancelled delivery orders with pos order state

PR #118288

Enterprisesaas-19.1pos_urban_piperpos_enterpriseMEDIUM

This update corrects a previous issue where cancelled food delivery orders remained active in the Point of Sale (PoS) system. Now, when a delivery order is cancelled through the aggregator, the PoS order automatically updates to reflect the cancelled state, ensuring accurate order tracking and preventing confusion for staff. This improves the overall customer experience and operational efficiency.

Original PR description

pos*: pos_urban_piper, pos_enterprise

When a food delivery order is cancelled from the aggregator side, the PoS order remains active on the frontend instead of reflecting the cancelled state.

Steps to reproduce:
- Configure UrbanPiper with Atlas
- Place an order via Atlas
- Open the order from the notification bar
- Cancel the order from Atlas

Issues:
- Cancelled orders continue to appear in `Draft`
- Accepted/preparation orders are not cancelled on the preparation display

Fix:
- Synchronise the PoS order state with the delivery state on cancellation
- Update preparation display orders when delivery orders are cancelled

Task-6217704

Forward-Port-Of: odoo/enterprise#118209
Forward-Port-Of: odoo/enterprise#117374

#pos#delivery#cancellation#urbanpiper

[FIX] html_editor: select empty styled table via move handle

PR #266155

Coresaas-19.1html_editor

This update fixes an issue where empty cells within styled tables weren't correctly recognized during selection using the HTML editor's move handle. Now, all table cells, even those with placeholder content, are properly selected when using the move handle and applying styling. This ensures consistent and reliable table selection within the HTML editor.

Original PR description

#### Description of the issue this PR addresses:
- Empty `.o_table` cells containing only placeholder ZWS content were not considered visible
- Full table selection via move handle failed to apply `o_selected_td` on styled empty cells

#### Desired behavior after PR is merged:
- Consider `.o_table` table cells visible

Steps to reproduce:
- Insert a table
- Select it via move handle
- Apply any color
- Click the move handle again to select the table

All table cells should have class `o_selected_td`

task-6208949

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

Forward-Port-Of: odoo/odoo#263836

#html_editor#table#selection

[FIX] sale_mrp_renting: prevent error when confirming a rental order

PR #118207

Enterprisesaas-19.1sale_mrp_rentingMEDIUM

This update resolves a bug that caused errors when confirming rental orders in versions 17 and 18, and a subsequent division-by-zero error in newer versions. The fix ensures the system correctly handles rental orders with kits, preventing errors and improving order processing reliability.

Original PR description

**Issue:**
In versions 17 and 18, a UserError is raised-
```
The unit of measure Units defined on the order line doesn't belong to the same
category as the unit of measure False defined on the product. Please correct
the unit of measure defined on the order line or on the product, they should
belong to the same category.
```

From version 18.2 onward, a different error occurs
```
ZeroDivisionError: float division by zero
```

**Root cause:**
In versions 17 and 18: At [1], since the BoM is created for a different variant , no BoM is found for the selected variant. As a result, when `_compute_quantity` is called at [2], the `bom.product_uom_id` is empty, which leads to the `UserError` from `_compute_quantity` method. In version 18.2+: At [1], as the BoM is empty. Then at [3], `_compute_kit_quantities` is called with an empty BoM, and at [4], this results in a division by zero error.

**Solution:**
Skip the computation when no BoM is found and directly return the quantity to avoid both the `UserError` and the `ZeroDivisionError`.

[1]https://github.com/odoo/enterprise/blob/eaa70dcab2b49eadca1cf36008dd80cfccbb8e4e/sale_mrp_renting/models/sale_order_line.py#L13
[2]https://github.com/odoo/enterprise/blob/eaa70dcab2b49eadca1cf36008dd80cfccbb8e4e/sale_mrp_renting/models/sale_order_line.py#L20
[3]https://github.com/odoo/enterprise/blob/eaa70dcab2b49eadca1cf36008dd80cfccbb8e4e/sale_mrp_renting/models/sale_order_line.py#L21
[4]
https://github.com/odoo/odoo/blob/91b09dbea5c8a306b5e9d2120466777f0248b360/addons/mrp/models/stock_move.py#L676

**opw-6082434**

Forward-Port-Of: odoo/enterprise#114176

#rental#order#kit

[FIX] hr_holidays: set explicit allocation start date in test

PR #266220

Coresaas-19.1hr_holidays

A test was failing due to a mismatch between the test environment's timezone and the internal calculations for leave allocation limits. This update ensures that leave allocation start dates are consistently evaluated in UTC, resolving the test failure and preventing incorrect leave limits from being reported. This improves the accuracy of leave tracking.

Original PR description

Issue: ----------------------------------- At certain times of the day (e.g., around midnight UTC), the test would fail deterministically ``` test_allocation_stats_with_duplicate_leave_type_names…

Issue:
-----------------------------------
At certain times of the day (e.g., around midnight UTC), the test would fail deterministically
```
test_allocation_stats_with_duplicate_leave_type_names
    self.assertEqual(leave_type_no_comp.with_context(employee_id=employee_id).max_leaves, 10)
AssertionError: 0.0 != 10
```

Cause:
-----------------------------------
This occurred due to a timezone mismatch during the test execution. When creating the `hr.leave.allocation`, `date_from` implicitly defaults to `fields.Date.context_today(self)` (which evaluates the date based on the test user's timezone, e.g., Europe/Brussels). However, the `max_leaves` computation in `hr.leave.type` evaluates valid allocations using `fields.Date.today()` as the target date (which strictly evaluates to the UTC date)

At certain times of day, this caused the allocation's `date_from` to evaluate to 'tomorrow' relative to the UTC `target_date`. Because the allocation was technically in the future relative to UTC, it was skipped during the computation causing `max_leaves` to return 0.0 instead of 10.

Solution:
-----------------------------------
Explicitly define `'date_from': date.today()` when creating the allocation in the test case. This perfectly aligns the allocation's starting date with the strict UTC evaluation used by the `max_leaves` computation under the hood.

Runbot Error: [937759](https://runbot.odoo.com/odoo/runbot.build.error/937759)
Related PR: https://github.com/odoo/odoo/pull/261680

Forward-Port-Of: odoo/odoo#265924
Forward-Port-Of: odoo/odoo#265703

#leave#timezones#testing

[FIX] sign: prevent empty values for constant auto-fields during signing

PR #118293

Enterprisesaas-19.1sign

This update resolves an issue where constant fields within signing documents would become empty during the signing process, leading to signing failures. The fix ensures that default field values are maintained when auto-fields return empty strings, preventing incorrect data and ensuring a smooth signing experience. This improves the reliability of our digital signature workflow.

Original PR description

Version:
- saas-18.4

Steps to reproduce:
- Create sign template.
- Add a sign item with read only true and linked model and auto_value field set.
- Send document for signing.
- Try to sign the document.

Issue:
- Signing fails with "Some required items are not filled".
- Constant readonly fields become empty during signing flow.

Cause:
- In `_populate_constant_items()`, the default field value was always replaced by `_get_auto_field_value()`.
- When no reference document was set, `_get_auto_field_value() `returned an empty string.
- This caused an empty value to be stored in `sign.request.item.value`.

Solution:
- Keep the default field value when auto-field resolution returns an empty string.
- Only replace the value when a valid auto-field value is found.

task-6229776

Forward-Port-Of: odoo/enterprise#118240
Forward-Port-Of: odoo/enterprise#117880

#sign#digital signatures#workflow

[FIX] base{,_import},account: prevent l10n module installation when importing

PR #266157

Coresaas-19.1baseaccountMEDIUM

This update resolves an issue where importing company data would incorrectly trigger the installation of localization (L10N) modules, leading to server errors and data corruption. The fix ensures that L10N modules are only installed when explicitly required, improving import stability and data integrity.

Original PR description

# How to reproduce
- Start from a fresh database
- Install the account module
- Import companies with a data file. These companies need to have a country set and the
data file needs to contain some bad data
- Click on the Test button

# The problem
An Odoo Server Error is displayed saying : "savepoint xxx does not exist", which prevents
the import or hides other potential error. More importantly, the date is imported even though it was a test run.

# Cause
Importing companies with a country will import their respective l10n modules using
`button_immediate_install()` :
https://github.com/odoo/odoo/blob/6de867f1c92bacedc0574b63e9e6a2a57fe805dd/odoo/addons/base/models/res_company.py#L319-L322
https://github.com/odoo/odoo/blob/661ddbb7f12e32394a3c11b5a4cd2f38a9e156f5/odoo/addons/base/models/res_company.py#L237

This import calls `cr.commit` :
https://github.com/odoo/odoo/blob/661ddbb7f12e32394a3c11b5a4cd2f38a9e156f5/odoo/addons/base/models/ir_module.py#L632-L634

The issue is that when importing a data file, we create savepoints :
https://github.com/odoo/odoo/blob/661ddbb7f12e32394a3c11b5a4cd2f38a9e156f5/odoo/orm/models.py#L971-L974

And if an error arise during our import, we rollback to the appropriate save point. Sadly,
commiting erases any existing save point, so a savepoint error is rased and the
data is not rolled back.

The problem stems from the fact that importing module is simply not transactionnal and
`button_immediate_install()` is not expected to be called with a savepoint. This
was already partly adressed by :
https://github.com/odoo/odoo/commit/66dcee9aa70dc72a332fde64dbc802266bbe4a5a

But it did not cover the file importing case

opw-6174983

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

Forward-Port-Of: odoo/odoo#265188

#import#data#stability

Issue before this commit: ========================= For products tracked by serial/lot with packaging units, the delivery slip correctly shows the packaging unit and quantity before validating the transfer. However, after validating the transfer, the packaging unit and its corresponding quantity are no longer displayed in the delivery slip report. Steps to Reproduce: ========================= 1. Install stock and sale_management modules. 2. Enable Units of Measure & Packagings and Display Lots & Serial Numbers on Delivery Slips from settings. 3. Create a product with tracking by lot/serial number and configure a packaging unit. 4. Create a SO using this product with a packaging unit and confirm it. 5. Open the related transfer and print the delivery slip before and after validation. Cause of the Issue: ========================= The delivery slip report template (stock_report_delivery_has_serial_move_line) does not display packaging unit information after validation for move lines when the packaging unit differs from the product unit of measure. With This Commit: ========================= This commit ensures that packaging units and their corresponding quantities are displayed on the delivery slip after validation when the packaging unit differs from the product unit of measure. Steps To Reporduce: [Video Link](https://drive.google.com/file/d/10DmFKW1Y_Tm-AyKzPrqtFMY8orBkKbIm/view?usp=sharing) opw-6142052 Forward-Port-Of: odoo/odoo#265206

pos*: pos_urban_piper, pos_enterprise When a food delivery order is cancelled from the aggregator side, the PoS order remains active on the frontend instead of reflecting the cancelled state. Steps to reproduce: - Configure UrbanPiper with Atlas - Place an order via Atlas - Open the order from the notification bar - Cancel the order from Atlas Issues: - Cancelled orders continue to appear in `Draft` - Accepted/preparation orders are not cancelled on the preparation display Fix: - Synchronise the PoS order state with the delivery state on cancellation - Update preparation display orders when delivery orders are cancelled Task-6217704 Forward-Port-Of: odoo/enterprise#118209 Forward-Port-Of: odoo/enterprise#117374

#### Description of the issue this PR addresses: - Empty `.o_table` cells containing only placeholder ZWS content were not considered visible - Full table selection via move handle failed to apply `o_selected_td` on styled empty cells #### Desired behavior after PR is merged: - Consider `.o_table` table cells visible Steps to reproduce: - Insert a table - Select it via move handle - Apply any color - Click the move handle again to select the table All table cells should have class `o_selected_td` task-6208949 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263836

**Steps to produce:** - Install `sale_mrp_renting`. - Enable `Rental Transfers` from settings. - Create a rental product. - Create two variants of the product. - Create a BoM for one variant and set its type to `Kit`. - Create a rental order using the other variant. - Try to confirm the order. **Issue:** In versions 17 and 18, a UserError is raised- ``` The unit of measure Units defined on the order line doesn't belong to the same category as the unit of measure False defined on the product. Please correct the unit of measure defined on the order line or on the product, they should belong to the same category. ``` From version 18.2 onward, a different error occurs ``` ZeroDivisionError: float division by zero ``` **Root cause:** In versions 17 and 18: At [1], since the BoM is created for a different variant , no BoM is found for the selected variant. As a result, when `_compute_quantity` is called at [2], the `bom.product_uom_id` is empty, which leads to the `UserError` from `_compute_quantity` method. In version 18.2+: At [1], as the BoM is empty. Then at [3], `_compute_kit_quantities` is called with an empty BoM, and at [4], this results in a division by zero error. **Solution:** Skip the computation when no BoM is found and directly return the quantity to avoid both the `UserError` and the `ZeroDivisionError`. [1]https://github.com/odoo/enterprise/blob/eaa70dcab2b49eadca1cf36008dd80cfccbb8e4e/sale_mrp_renting/models/sale_order_line.py#L13 [2]https://github.com/odoo/enterprise/blob/eaa70dcab2b49eadca1cf36008dd80cfccbb8e4e/sale_mrp_renting/models/sale_order_line.py#L20 [3]https://github.com/odoo/enterprise/blob/eaa70dcab2b49eadca1cf36008dd80cfccbb8e4e/sale_mrp_renting/models/sale_order_line.py#L21 [4] https://github.com/odoo/odoo/blob/91b09dbea5c8a306b5e9d2120466777f0248b360/addons/mrp/models/stock_move.py#L676 **opw-6082434** Forward-Port-Of: odoo/enterprise#114176

Issue: ----------------------------------- At certain times of the day (e.g., around midnight UTC), the test would fail deterministically ``` test_allocation_stats_with_duplicate_leave_type_names self.assertEqual(leave_type_no_comp.with_context(employee_id=employee_id).max_leaves, 10) AssertionError: 0.0 != 10 ``` Cause: ----------------------------------- This occurred due to a timezone mismatch during the test execution. When creating the `hr.leave.allocation`, `date_from` implicitly defaults to `fields.Date.context_today(self)` (which evaluates the date based on the test user's timezone, e.g., Europe/Brussels). However, the `max_leaves` computation in `hr.leave.type` evaluates valid allocations using `fields.Date.today()` as the target date (which strictly evaluates to the UTC date) At certain times of day, this caused the allocation's `date_from` to evaluate to 'tomorrow' relative to the UTC `target_date`. Because the allocation was technically in the future relative to UTC, it was skipped during the computation causing `max_leaves` to return 0.0 instead of 10. Solution: ----------------------------------- Explicitly define `'date_from': date.today()` when creating the allocation in the test case. This perfectly aligns the allocation's starting date with the strict UTC evaluation used by the `max_leaves` computation under the hood. Runbot Error: [937759](https://runbot.odoo.com/odoo/runbot.build.error/937759) Related PR: https://github.com/odoo/odoo/pull/261680 Forward-Port-Of: odoo/odoo#265924 Forward-Port-Of: odoo/odoo#265703

Version: - saas-18.4 Steps to reproduce: - Create sign template. - Add a sign item with read only true and linked model and auto_value field set. - Send document for signing. - Try to sign the document. Issue: - Signing fails with "Some required items are not filled". - Constant readonly fields become empty during signing flow. Cause: - In `_populate_constant_items()`, the default field value was always replaced by `_get_auto_field_value()`. - When no reference document was set, `_get_auto_field_value() `returned an empty string. - This caused an empty value to be stored in `sign.request.item.value`. Solution: - Keep the default field value when auto-field resolution returns an empty string. - Only replace the value when a valid auto-field value is found. task-6229776 Forward-Port-Of: odoo/enterprise#118240 Forward-Port-Of: odoo/enterprise#117880

# How to reproduce - Start from a fresh database - Install the account module - Import companies with a data file. These companies need to have a country set and the data file needs to contain some bad data - Click on the Test button # The problem An Odoo Server Error is displayed saying : "savepoint xxx does not exist", which prevents the import or hides other potential error. More importantly, the date is imported even though it was a test run. # Cause Importing companies with a country will import their respective l10n modules using `button_immediate_install()` : https://github.com/odoo/odoo/blob/6de867f1c92bacedc0574b63e9e6a2a57fe805dd/odoo/addons/base/models/res_company.py#L319-L322 https://github.com/odoo/odoo/blob/661ddbb7f12e32394a3c11b5a4cd2f38a9e156f5/odoo/addons/base/models/res_company.py#L237 This import calls `cr.commit` : https://github.com/odoo/odoo/blob/661ddbb7f12e32394a3c11b5a4cd2f38a9e156f5/odoo/addons/base/models/ir_module.py#L632-L634 The issue is that when importing a data file, we create savepoints : https://github.com/odoo/odoo/blob/661ddbb7f12e32394a3c11b5a4cd2f38a9e156f5/odoo/orm/models.py#L971-L974 And if an error arise during our import, we rollback to the appropriate save point. Sadly, commiting erases any existing save point, so a savepoint error is rased and the data is not rolled back. The problem stems from the fact that importing module is simply not transactionnal and `button_immediate_install()` is not expected to be called with a savepoint. This was already partly adressed by : https://github.com/odoo/odoo/commit/66dcee9aa70dc72a332fde64dbc802266bbe4a5a But it did not cover the file importing case opw-6174983 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265188