Odoo Changelog — 2025-10-06

Monday, October 6, 2025

3 changes · 17.0

Bug Fixes(3)

Resolved issues and error corrections

[FIX] hr_holidays: prevent multi-day display of single-day leaves

Core17.0hr_holidaysMEDIUM

Fixed an issue where one-day time off requests could appear as multi-day events in the Calendar app for users in certain time zones. This helps employees and managers see accurate leave schedules and avoids confusion when planning coverage.

Original PR description

**Issue:** Single-day time off requests appear as multi-day events in the Calendar app when using certain tim> **Cause:** The `_compute_date_from_to()` method converts user-specified dates to UTC.…

**Issue:**

Single-day time off requests appear as multi-day events in the Calendar app when using certain tim>

**Cause:**

The `_compute_date_from_to()` method converts user-specified dates to UTC. https://github.com/odoo/odoo/blob/028e7228cb830e47a9726bef4c82793ba4590cd5/addons/hr_holidays/models/hr_leave.py#L316-L317
 The `_prepare_holidays_meeting_values()` method then uses these UTC datetime values (`holiday.date_from`, `holiday.date_to`)

In Los Angeles timezone, and for a one day leave on september 17 2025 this leads to:

- holiday.date_from: September 17, 2025 at 03:00 UTC
- holiday.date_to: September 18, 2025 at 12:00 UTC

causing a single-day leave to be displayed as a two-day event.

**After fix:**

- start_value: September 17, 2025 at 12:00
- stop_value: September 17, 2025 at 11:59

**Steps to Reproduce:**

1. Set the user timezone to "America/Los_Angeles"
2. Set the browser timezone to the same timezone
3. Create a one-day time off request (e.g., September 17, 2025)
4. Open the Calendar app: the event spans across two days

opw-4744817

#time-off#calendar#timezone

[FIX] l10n_uk_reports: remove garbage value from localStorage

PR #87335

Enterprise17.0l10n_uk_reportsMEDIUM

This update clears invalid saved device identifiers before sending UK tax report requests to HMRC. It helps prevent repeated submission failures caused by outdated or corrupted browser-stored values.

Original PR description

There are still Odoo requests that are sent to hmrc with invalid
'Gov-Client-Device-ID' header.  They are showing this error:
"Submit a UUID which is 128 bits or 32 hex characters long".

A possible explanation, is that some users have some garbage value
in the localStorage for 'hmrc_gov_client_device_id', that does not
correspond to a uuid.  This value would then be sent each time in the
headers, and get rejected.

The fix here is to clear the localStorage value if it is not a uuid.

task-4627086

#UK localization#HMRC#tax reports#submission reliability

[FIX] point_of_sale: price based on min qty on lot

PR #219110

Core17.0point_of_saleMEDIUM

Point of Sale now applies quantity-based pricelist rules correctly when the same lot-tracked product is split across multiple lots. This prevents customers from missing eligible pricing when their total purchased quantity meets the rule threshold, even if it appears on separate POS lines.

Original PR description

**PROBLEM**
Pricelist rules based on a minimum quantity does not work well with lot tracked product, when the quantity is splitted between multiples lots. For example, if you take 2 product from lot A, and 3 product from lot B, a rule defining the price for a minimum quantity of 5 will not trigger (it should).

**STEP TO REPRODUCE**
1. install pos
2. create a lot tracked product
3. create a pricelist rule for the product, with a price based on min qty
4. from the pos, order the min qty but split it accross multiple lots
5. price will not takethe rule into account

**CAUSE**
Order line of lot tracked products are never merged. The quantity used to compute if a pricelist trigger is the quantity of each line individually.

**FIX**
For lot tracked product, to determine the price of a line, we parse find all corresponding lines and add their quantities together. Then we update all of their prices. To know if we should take into account a line, we verify if they would have been merged, if their product wasn't lot tracked.

**REMARK**
Ideally, their would be a way to merged order line of lot tracked product, while being able to edit the quantity taken from each lot directly from the pos. From now, order line doesn't work well with multiple lots, and it would require unstable change on the db.

opw-4751920

#pos#pricelist#lot tracking#pricing

**Issue:** Single-day time off requests appear as multi-day events in the Calendar app when using certain tim> **Cause:** The `_compute_date_from_to()` method converts user-specified dates to UTC. https://github.com/odoo/odoo/blob/028e7228cb830e47a9726bef4c82793ba4590cd5/addons/hr_holidays/models/hr_leave.py#L316-L317 The `_prepare_holidays_meeting_values()` method then uses these UTC datetime values (`holiday.date_from`, `holiday.date_to`) In Los Angeles timezone, and for a one day leave on september 17 2025 this leads to: - holiday.date_from: September 17, 2025 at 03:00 UTC - holiday.date_to: September 18, 2025 at 12:00 UTC causing a single-day leave to be displayed as a two-day event. **After fix:** - start_value: September 17, 2025 at 12:00 - stop_value: September 17, 2025 at 11:59 **Steps to Reproduce:** 1. Set the user timezone to "America/Los_Angeles" 2. Set the browser timezone to the same timezone 3. Create a one-day time off request (e.g., September 17, 2025) 4. Open the Calendar app: the event spans across two days opw-4744817

There are still Odoo requests that are sent to hmrc with invalid 'Gov-Client-Device-ID' header. They are showing this error: "Submit a UUID which is 128 bits or 32 hex characters long". A possible explanation, is that some users have some garbage value in the localStorage for 'hmrc_gov_client_device_id', that does not correspond to a uuid. This value would then be sent each time in the headers, and get rejected. The fix here is to clear the localStorage value if it is not a uuid. task-4627086

**PROBLEM** Pricelist rules based on a minimum quantity does not work well with lot tracked product, when the quantity is splitted between multiples lots. For example, if you take 2 product from lot A, and 3 product from lot B, a rule defining the price for a minimum quantity of 5 will not trigger (it should). **STEP TO REPRODUCE** 1. install pos 2. create a lot tracked product 3. create a pricelist rule for the product, with a price based on min qty 4. from the pos, order the min qty but split it accross multiple lots 5. price will not takethe rule into account **CAUSE** Order line of lot tracked products are never merged. The quantity used to compute if a pricelist trigger is the quantity of each line individually. **FIX** For lot tracked product, to determine the price of a line, we parse find all corresponding lines and add their quantities together. Then we update all of their prices. To know if we should take into account a line, we verify if they would have been merged, if their product wasn't lot tracked. **REMARK** Ideally, their would be a way to merged order line of lot tracked product, while being able to edit the quantity taken from each lot directly from the pos. From now, order line doesn't work well with multiple lots, and it would require unstable change on the db. opw-4751920