Issue:
When updating partner fields such as `email`, `name` and `phone` on the partner records,
the ticket fields are recomputed. During the recomputation, the `description` field is loaded into memory and with
many helpdesk tickets, this will cause a memory error.

Purpose of this PR:
To explicity fetch `partner_id` before computing partner fields on the helpdesk ticket.

Example:
With a partner record with 25,000 helpdesk tickets each with a description of varying text and images,
we hit the memory limit when trying to update the partner phone. With these changes, peak memory usage reached 271.4 MB.

Notes:
Originally wanted to avoid changing the field definition however this would require adding `with_context(prefetch_fields=False)`
to most of the compute methods on helpdesk ticket model.`with_context(prefetch_fields=False)` to most of the compute methods on helpdesk ticket model.

Memgraph and Stats before changes
<img width="1912" height="862" alt="memgraph_b4_changes" src="https://github.com/user-attachments/assets/f5e95a42-83c8-4250-bdf3-440740a9fb33" />
<img width="640" height="352" alt="stats_b4_changes" src="https://github.com/user-attachments/assets/a82ccd69-1359-4ba8-81a0-52aeace762db" />


opw-5069424

Forward-Port-Of: odoo/enterprise#96198

The previous fix for `message/rfc822` attachments forced binary encoding (`cte='binary'`) to comply with RFC 2046. However it also introduced a new issue: emails containing `.eml` attachments with non-ASCII characters could not be serialized

### Steps to reproduce

1. Send an email via the chatter with a `.eml` file attached containing non-ASCII characters (e.g., "é") in its body.

The sending of that email will fail with a `UnicodeEncodeError` error

### Cause

Commit 6197233ef1611ddd974cfdb06ae2568e4af369de attempted to fix an issue where `.eml` (`message/rfc822`) attachments were not RFC-compliant. It did this by forcing the `Content-Transfer-Encoding` to `binary` for the raw byte content of the attachment.

While this worked for simple ASCII attachments, it failed for attachments containing non-ASCII characters. When Python's `email` library later tried to serialize the entire message, it treated the attachment's content as an opaque binary blob. It did not understand the character encoding within that blob, leading to a `UnicodeEncodeError` during the final serialization process.

### Fix

Instead of attaching the raw bytes, we now:
* Parse `.eml` contents using `email.parser.BytesParser`, producing a proper `Message` object.
* Attach the parsed message directly, letting the email library handle correct encoding and transfer settings automatically.

opw-4655868

Forward-Port-Of: odoo/odoo#230384
Forward-Port-Of: odoo/odoo#223790

**Problem:**
unbuilding a Manufactring order created through a subcontracting
process gives the wrong account move lines

**Steps to reproduce:**
- create a storable product (the comp) and set a cost
- create a storable product (the final product), set a cost
and set a vendor
- for the final product set the category as avco and automated
- for the final product create a bill of materials subcontracted
 and set the same vendor
- for the components add the comp for a quantity of 1
- create a Purchase order for the final product and the same vendor
and confirm
- validate the receipt
- From the receipt click on the valuation smart button and click on 
the book widget of the line of the final product
- notice how there is 3 journal items line including one 
crediting "stock interim (Received)"
- unarchive the operation type "subcontracting"
- open Manufacturing/Manufacturing Orders, delete the "to do" 
filter and search for a Manufacturing order with your final product
- unbuild it
- Open accounting/journal entries and select the journal entry for 
the unbuild

**Current behavior:**
There is only two account lines. 
There is no line balancing the "Stock Interim" line of the
manufacturing order.

**Cause of the issue:**
The override of _generate_valuation_lines_data in
mrp_subcontracted_account adds the stock interim line on the 
manufacturing order.
However when unbuilding, the qty is negative so we exit the function
https://github.com/odoo/odoo/blob/1358f93a4c73de5a28cda72ec78769625c863efd/addons/mrp_subcontracting_account/models/stock_move.py#L20

**fix**
Because subcontracted Manufacturing orders are not meant 
to be unbuilt, we prevent it

opw-4998137

Forward-Port-Of: odoo/odoo#230062

Serial number tracked product are marked as pass even when they fail a move_line type of check.

### Steps to reproduce:

* Create a product tracked by serial number
* For this product create a control point:
	- Control per quantity
	- Operations : Receipts
* Create a receipt for this product
* Mark the receipt as Todo
* Start the Quality check from the receipt, without using the smart button.
* Fail the Quality check
* The Quality check still passes

### Issue:

When validating a quality check and it fails:
https://github.com/odoo/enterprise/blob/d48228127c239e45938551d9bbac734afab8b31a/quality_control/wizard/quality_check_wizard.py#L84-L92 I will not go through the standard process with show_faillure_message where the user can select failed_qty, it directly goes to confirme_fail>_move_to_failure_location: https://github.com/odoo/enterprise/commit/49149580d34ec5583559fa0288356fec6cb2c514#diff-2ffdc2ffc25417076b580b772447514c7e9d8b3e2d2fff2d3100721eb5ccbaf4L455-R457 In our case since failed_qty is still at 0 this new condition transfer the quality check to pass. In the case of serial numbers, the quality check is done one by one, the failed_qty can be retrived from check.move_line_id.quantity

opw-5015266

Forward-Port-Of: odoo/enterprise#92966

### Steps to reproduce:
1. Install mrp + purchase
2. Create a new product (A)
   1. Add the Buy route on the product
   2. Add a vendor line on the Purchase tab
   3. Set the quantity on hands to 2000
3. Create a second product (B) with manufacturing route
4. Create a BoM for this product (B)
   1. Add the product (A) as the component with 1 quantity
   2. Create a new operation with a duration of 600:00
5. On the product B's page, click Replenish
   1. Put 10 quantities to replenish
   2. Select the manufacturing route and confirm
6. Go to the BoM and open the BoM overview
7. 'Impossible to plan. Please check the workcenter availabilities.'

https://github.com/user-attachments/assets/58697fd9-4e3e-4df6-98e1-5de7e8759715


### Before this commit:
When opening the BoM overview, if the producible quantity for this BoM exceed the quantity we can plan in the 700 following days, an error is displayed.

### After this commit:
If the quantity producible cannot be planned, we retry automatically with the requested quantity.

opw-5031724

Forward-Port-Of: odoo/odoo#229745
Forward-Port-Of: odoo/odoo#227433

**Steps to reproduce:**
- Install l10n_in and l10n_in_hr_holidays module
- Time off > configuration > Public holidays
- Create a public holiday for Independence Day (15/08/2025)
- Go to Time off > configuration > 'Time off Types',
- Create a Time off type with
   - 'Sandwich leave' ticked and `Take Time Off in` to half a day
- Go to Time off > Management > Time off
- Case 1: Create a paid time off leave for the employee from 13/08 to 17//08/2025 
- Case 2: Create a paid time off with any date and mark it as a half-day

**Observation:**
- Case 1: You will see Duration 3 days with the sandwich leave policy.
- Case 2: Half-day leave shows 1 day instead of 0.5

**Root Cause:**
- Case 1: For the sandwich leave rule, here we checked only one day after and before, leave start and leave end, respectively. It will cause an issue if an employee applies leave that starts or ends with 3 non-working days.
https://github.com/odoo/odoo/blob/5d2f1510c08d5570fc2c6c8de0cb4042bacf12d6/addons/l10n_in_hr_holidays/models/hr_leave.py#L39-L46
- Case 2: We forcefully added a 1-day leave, without checking if the leave is half day or not.
https://github.com/odoo/odoo/blob/5d2f1510c08d5570fc2c6c8de0cb4042bacf12d6/addons/l10n_in_hr_holidays/models/hr_leave.py#L19

**Solution:**
- Case 1: Extend the sandwich leave logic to check every day before and after until a working day is found.
- Case 2: Fixed duration calculation to add 0.5 for half-day leaves.

opw-5025766

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

Forward-Port-Of: odoo/odoo#226883

### Issue:

To reproduce the bug:
1. Activate `Packages` settings in Inventory:
2. Activate `Move entire packages` on picking type `delivery orders`
3. Create new product `Test move package`
4. Update quantity in `WH/Stock` with a newly created package and a qty (eg 5)
5. Go to the delivery orders and create a new picking with the created product and a quantity of 5
6. Click on `Mark as Todo`, the picking is set as ready and a package level is created automatically to move the quantity we did put in stock in the package.
7. Mark the checkbox `Done` on the package level (this will mark the move line and the move as picked)
8. Unmark the checkbox `Done` on the package level.

The package level is deleted, as well as the stock move line,
but the stock move still has the checkbox picked that is
marked.
The picking is then in waiting state and we cannot check
availability again.
Currently to be able to check the availability, the picked
check should be undone manually.

### Cause of issue

Currently, in `_compute_picked` in `stock_move`, we don't
update value of move.picked if there is `no move_line_ids`
present which is wrong.

### Fix:

In the fix, picked is set to False when there no
`move_line_ids`

### Issue 2

This fix cause another issue, in which the move loses its `picked` status after manually setting the done quantity when no stock was initially available,

### Cause of issue 2

To be more specific this fix on `_compute_picked`
```diff
- elif move.move_line_ids:
        move.picked = False
+ else:
        move.picked = False
```
has the following side effect:
- On a confirmed picking, pick a move with a quantity of 0 then change the quantity to 10 the move is unpicked -> undesirable.

After you picked the move, when you set the quantity, you will set `move_line_ids` on your move to match the quantity increase here:
https://github.com/odoo/odoo/blob/57c0ce5f0af9b46c037759d85205bc3e88890af7/addons/stock/models/stock_move.py#L2157-L2165
However,`self._set_quantity_done_prepare_vals(qty)` does not return a `stock.move.line` record set but a `Command.create` whose values do not contain any info on the picked value of the move *line*:
https://github.com/odoo/odoo/blob/57c0ce5f0af9b46c037759d85205bc3e88890af7/addons/stock/models/stock_move.py#L1497-L1507
The fact that the `move_line_ids` is set on the move to this command.create, flags the `picked` field of the stock move to dirty and adds it to the field to recompute because of the dependency `move_line_ids.state`:
https://github.com/odoo/odoo/blob/57c0ce5f0af9b46c037759d85205bc3e88890af7/addons/stock/models/stock_move.py#L208-L209
https://github.com/odoo/odoo/blob/57c0ce5f0af9b46c037759d85205bc3e88890af7/odoo/api.py#L795-L800
THEN, the creation of the move.line happends and since the value of the picked was not set in the command.create, we populate it based on the picked value of the move:
https://github.com/odoo/odoo/blob/57c0ce5f0af9b46c037759d85205bc3e88890af7/addons/stock/models/stock_move_line.py#L347-L348
However, at this point since the picked value of the move has been flagged as dirty it is recomputed using the `compute_method` modified in our fix.
And since the move does not have any move line at this stage, it is computed to be picked = False resetting the picked value.

### Fix of Issue 2:
We should set the picked values in the vals here:
https://github.com/odoo/odoo/blob/57c0ce5f0af9b46c037759d85205bc3e88890af7/addons/stock/models/stock_move.py#L1497-L1507

opw-4964561


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

Forward-Port-Of: odoo/odoo#222034