Steps to reproduce:
---------------------------
1. Install Timesheets
2. Open Timesheets > All Timesheets and observe the overtime indicator
for an employee with a fully fixed working schedule (e.g. Mitchell Admin).
(Click on the left arrow to see the overtime indicator)
3. Enable flexible hours on the employee’s working schedule.
4. Go back to Timesheets and observe the overtime indicator.

Issue:
--------
The overtime indicator displays incorrect values for employees
with flexible working schedule

Cause:
---------
https://github.com/odoo/enterprise/blob/8b00363e5e461f11b9736354d94e520e21932e71/timesheet_grid/models/hr_employee.py#L21-L24 In `_get_employees_working_hours`, date strings are converted
to naive datetimes and day boundaries (`start_datetime` and `end_datetime`)
are created using a full-day range (00:00:00 to 23:59:59.999) before being
assigned UTC via `.replace(tzinfo=UTC)`.

When these boundaries are later processed by [_attendance_intervals_batch](https://github.com/odoo/odoo/blob/42ea101c80c0c593ff85b9c06e34fbf1161d0387/addons/resource/models/resource_calendar.py#L370-L371)
method using [resource timezone](https://github.com/odoo/odoo/blob/42ea101c80c0c593ff85b9c06e34fbf1161d0387/addons/resource/models/resource_calendar.py#L304-L305), the end-of-day boundary (23:59:59 UTC)
shifts into the next day for positive offset time zones (e.g., IST).

**Example:**
2026-02-07 23:59:59 UTC becomes 2026-02-08 05:29:59 IST, causing
the calculation to include hours from an unintended additional day.

Solution:
-----------
Localize the naive datetimes using the resource timezone before converting them to UTC.

Before(Flexible 40 hours/week):
<img width="1910" height="271" alt="image" src="https://github.com/user-attachments/assets/77f9a66b-670c-444b-9165-bcc6f4301737" />

After(Flexible 40 hours/week):
<img width="1920" height="254" alt="image" src="https://github.com/user-attachments/assets/3671bbf9-1425-48e6-a654-45753274872c" />


opw-5899109

Steps to produce:
---
- Install `mrp`.
- Go to Manufacturing > Products > Bills of Materials.
- Click Create, select a product.
- In the Product Variant field, type any value and click "Create".

Issue:
---
Using quick create on the Product Variant field does
not create a variant of the selected product template. Instead, it
creates a completely new, unrelated `product.template`. This is because
the `create()` method on `product.product` is overridden to call super()
with context `create_product_product=False`, which suppresses direct
variant creation and forces creation through `product.template` instead,
see [1].

**Why passing `default_product_tmpl_id` does not help:**
One might expect that passing `default_product_tmpl_id` in the field
context would cause the newly quick-created `product.product` to be
linked to the already-selected `product.template`. However, because of
the `create()` override above (introduced in [commit]), the variant
creation is always redirected to `product.template`, ignoring any
`default_product_tmpl_id` passed in context. It is therefore not possible
in any case to quick-create a `product.product` that is correctly and
directly linked to the currently selected `product.template`.

Fix:
---
Disable the "Create" and "Create and Edit" options. Since there is no
way to quick-create a `product.product` that is correctly linked to the
currently selected `product.template`, the user must create the variant
directly on the product template first.

[1]https://github.com/odoo/odoo/blob/f04d79d44873d0f1c35303a1a892f3a3a394ea17/addons/product/models/product_product.py#L364-L368

[commit]: https://github.com/odoo/odoo/commit/7389345696720255a9d3c72ca1d9c2f4e4ecd7b8

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

Forward-Port-Of: odoo/odoo#259776

Prior to this fix, the parser walked through message parts that should have been ignored.

Emails utilize the MIME mechanism (RFC 2045), where the structure of an email is defined by boundaries that delineate different parts. Each part contains its own Content-Type (RFC 2045) and an optional Content-Disposition (RFC 2183). The Content-Type header describes the body content so the receiving user agent can select the appropriate mechanism to present the data. The Content-Disposition header defines whether the content should be displayed inline (in Odoo, understand this has "add it in the body") or treated as an attachment (in Odoo, create an ir.attachment and attach it to this mail.message). See `_message_parse_extract_payload` in https://github.com/odoo/odoo/blob/9218d302b0fd56c1854d95d3756c0f5e9c9c8700/addons/mail/models/mail_thread.py#L1547-L1549


The Issue:
When an email has a `Content-Type: message/rfc822`, it contains the body of a previously sent EML as an attachment. This embedded message possesses its own internal boundaries and parts. These sub-parts should not be processed as part of the top-level email’s primary structure.

In the case of opw-5892642, the email contained two text/html parts: one in the main email and one within the message/rfc822 attachment. The parser incorrectly reached into the attachment, allowing the second text/html part to override the first, leading to significant data loss. This override occurred within the _message_parse_extract_payload function: https://github.com/odoo/odoo/blob/9218d302b0fd56c1854d95d3756c0f5e9c9c8700/addons/mail/models/mail_thread.py#L1615-L1618


The Fix:
The new implementation adopts the logic used in the CPython email library iterator (cpython/Lib/email/iterators.py), specifically the _structure function. The updated logic ensures the parser walks through the mail structure without descending into nested levels it should ignore, staying focused only on the relevant part.

RFC1341 - 7.3.1:
A Content-Type of "message/rfc822" indicates that  
the  body contains  an encapsulated message, 
with the syntax of an RFC 822 message.

opw-5892642

Issue
-----
When there is a packaged quant in stock, the `least package` removal strategy has unexpected behaviour.

Steps to reproduce
-----
- Enable packages
- Create a product AAA tracked by SN
	- product category removal strategy set to "Smallest number of packages"
- Create a reception for 5 units
	- Generate serials
	- Put last line in pack
- Confirm reception
- Create delivery for 2 units of AAA
	- Mark as Todo
	- Change the quants taken: instead of SN 5, take SN 3 (so take SN 3 & 4)
- Create a delivery for 3 units of AAA
	- Mark as Todo

> Quantity reserved is one, it only reserved SN 5

Cause
-----
The problem arises in `_run_least_packages_removal_strategy_astar`. Because there is an available quant inside a package, we continue past

https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L675-L676

We end up at

https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L724

The `generate_domain` function has a problem: if there sin't enough products inside packages to satisfy the demand, it searches for items not in packages to take from.

https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L701-L705

This search is flawed, because it does not take into account the fact that the quant might already be reserved. So it expands the domain with an `AND` on quant ids that are not available.

This leads to `quants` in `_get_reserve_quantity` containing unavailable quants

https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L866

This later gets "caught" in `available_quantity`

https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L897

and the quants don't get reserved a second time thanks to

https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L912-L914

but this also means the reservation is incomplete.

Note that calling `action_assign` a second time will correctly reserve the remaining quantities, as there is no package left to reserve in stock, so we do go in

https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L675-L676

and avoid the faulty logic.

Solution
-----
Ideally, we would use the value of `available_quantity` in our search domain. However, the field is not stored

https://github.com/odoo/odoo/blob/c359e21457ca3adf5ca713b7aa30e198d0b08f7c/addons/stock/models/stock_quant.py#L88-L91

Our options are:
- make the field stored (not stable)
- add a search function
- filter reserved quants out of `single_item_ids`

First option is not stable. Second option requires subqueries to compare `quantity` and `reserved_quantity`. Third option is the least bad one, with only a very situational performance loss.

-----
Ticket:
opw-5972350

Steps to reproduce:
------------------------
1. Install the Helpdesk.
2. Go to Settings → Technical → Sequences and set the next number to 100.
3. Create a ticket and send a message using the "Helpdesk: Ticket Received"
mail template; Observe that the correct reference (100) is used.
(Open the full composer to use "Load template")
4. Now send a message using the "Helpdesk: Ticket Closed" mail template
and Observe that it displays the database ID (e.g., 1) instead of the reference.


Cause:
------
`new_ticket_request_email_template` uses the ticket reference(`object.ticket_ref`) correctly.
https://github.com/odoo/enterprise/blob/d39e291ba89ad018ba6f5f9591d280a834822f27/helpdesk/data/mail_template_data.xml#L18-L19

However, the `solved_ticket_request_email_template` uses the database ID (`object.id`)
instead of the actual ticket reference (`object.ticket_ref`), leading to inconsistent references
in customer communications.

related commit: 3ed5273

Solution:
---------
Update `solved_ticket_request_email_template` to use `object.ticket_ref` instead of `object.id`

opw-6087466

Forward-Port-Of: odoo/enterprise#113932

Steps to reproduce
1. Install l10n_ar (or any LATAM localization).
2. Go to Accounting > Configuration > Journals and open a Purchase journal
   that has "Use Documents?" enabled.
3. Enable "Secure Posted Entries with Hash".
4. Create and post a vendor bill with a high document number (e.g. 00001-00009999).
5. Create another vendor bill with a lower document number (e.g. 00001-00000100)
   and try to post it.

Issue
Posting the second vendor bill fails with:
"This move could not be locked either because some move with the same sequence
prefix has a higher number. You may need to resequence it."

The hashing logic in account_journal.py enforces a strict continuous sequential
chain per journal:
https://github.com/odoo/odoo/blob/89993885823f7309b921145eacc7bbe2c3c1e427/addons/account/models/account_journal.py#L671-L678

In LATAM countries, vendor bill document numbers are assigned by the vendor, not
by Odoo. A bill with a lower number can legitimately be entered after one with a
higher number, which breaks the sequential assumption the hash chain relies on.
Allowing it would produce a hash that no longer represents a proper chain, giving
users a false sense of security. Sales journals are unaffected because Odoo
controls their sequence.

Solution
Hide the "Secure Posted Entries with Hash" field on purchase journals that have
"Use Documents?" enabled, preventing users from enabling an option that cannot
work correctly for vendor-assigned document numbers. Sales journals keep the
option available since Odoo controls their sequence.

opw-6076673