Currently, an error occurs when trying to add an attachment after saving an
invoice email as a template in the `Send wizard`.

**Steps to produce:**
- Install the `account` module.
- Create a new invoice, fill in all required details, then `confirm` and click `Send`.
- Click the `three-dot (⋮)` menu and select `Save as Template`, enter a name,
  and save the template.
- Try to add an attachment.

**Error:**
`AttributeError: 'account.move.send.wizard' object has no attribute '_mail_post_access'`
`AttributeError: 'account.move.send.wizard' object has no attribute '_get_thread_with_access'`

Root **cause:**
At [1], the code sets a new `template_id` when the template is saved. This
triggers `_compute_model()` at [2], which updates the model field to
`account.move.send.wizard` instead of `account.move`, using the `active_model`
context, causing the `error`.

**Fix:**
This commit ensures that after saving a mail template, the wizard retains the
correct model, same as [3], and prevents the attachment upload error.

[1]:
https://github.com/odoo/odoo/blob/5c6afcbffb49803a03e3a384ed60de68093dca04/addons/account/wizard/account_move_send_wizard.py#L296

[2]:
https://github.com/odoo/odoo/blob/5c6afcbffb49803a03e3a384ed60de68093dca04/addons/account/wizard/account_move_send_wizard.py#L244-L248

[3]:
https://github.com/odoo/odoo/blob/5c6afcbffb49803a03e3a384ed60de68093dca04/addons/mail/wizard/mail_compose_message.py#L380-L389

sentry-6987172677

Forward-Port-Of: odoo/odoo#234268

While investigating a few support tickets related to how the l10n_cl override the fetch mail methods, we noticed a more general issue:

As of now, the payload parsing business logic of Odoo can't handle emails encoding parts with `charset=cp-850`.

This is due to the fact that `cp-850` is not a accepted/standard encoding alias for cp850 charsets in python's `encoding` library.

Whether or not a mail stack should generate mail using `charset=cp-850` or not, we this fix aims at pro-actively declaring `cp-850` as a valid alias for cp850, so that implicitly the email CPython library can correctly decode the payloads in emails.

### Before this bug:

Sending a mail using `charset=cp-850` would generate a traceback.

Example:
```
From: Sender Name <sender@example.com>
To: Recipient Name <odooalias@example.com>
Subject: Test Email with CP-850 Encoding
Date: Thu, 13 Nov 2025 12:00:00 +0100
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----------=_4987654321-00000000"

This is a multi-part message in MIME format.
------------=_4987654321-00000000
Content-Type: text/plain; charset=cp-850
Content-Transfer-Encoding: quoted-printable

Hallo, dit is een test met een =82 speciale letter.
=
------------=_4987654321-00000000--
```

Would generate:
```
  File "/home/odoo/src/odoo/addons/mail/models/mail_thread.py", line 1398, in message_process
    msg_dict = self.message_parse(message, save_original=save_original)
  File "/home/odoo/src/odoo/addons/mail/models/mail_thread.py", line 1792, in message_parse
    msg_dict.update(self._message_parse_extract_payload(message, msg_dict, save_original=save_original))
  File "/home/odoo/src/odoo/addons/mail/models/mail_thread.py", line 1592, in _message_parse_extract_payload
    content = part.get_content()
  File "/home/odoo/miniconda3/lib/python3.10/email/message.py", line 1096, in get_content
    return content_manager.get_content(self, *args, **kw)
  File "/home/odoo/miniconda3/lib/python3.10/email/contentmanager.py", line 22, in get_content
    return self.get_handlers[maintype](msg, *args, **kw)
  File "/home/odoo/miniconda3/lib/python3.10/email/contentmanager.py", line 67, in get_text_content
    return content.decode(charset, errors=errors)
LookupError: unknown encoding: cp-850
```

### After fix:
`content = part.get_content()` correctly handles the `cp-850` alias

OPW-5171501
OPW-5247486


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

Forward-Port-Of: odoo/odoo#235529

When creating a new allocation,
selecting "Accrual" with an accrual plan, and then re-selecting "Regular," the accrual plan is registered in the backend,
Flush accrual_plan_id when changing the allocation type.

### **Steps to reproduce:**

1. Create a test database (version 17 or later).
2. Install the `hr_holidays` module.
3. In the Time Off module, navigate to Allocations.
4. Create a new allocation.
5. Select "Accrual Allocation" and assign an accrual plan.
6. Change the allocation type back to "Regular Allocation" and save.
7. Verify the accrual plan is registered in the backend.

**Note:** The accrual_plan_id field is displayed for visibility.

**Before Fix:**
<img width="1897" height="610" alt="before_allocation" src="https://github.com/user-attachments/assets/357c6c1d-3d57-4d2e-bf23-1cf260897aa1" />
<img width="1894" height="477" alt="before" src="https://github.com/user-attachments/assets/af193cd9-2e61-4fa9-8488-927e899ca574" />

```python3
test_17=# select id,private_name,allocation_type,accrual_plan_id from hr_leave_allocation where id = 18;
 id |   private_name    | allocation_type | accrual_plan_id 
----+-------------------+-----------------+-----------------
 18 | Before allocation | regular         |               1
(1 row)
```

**After Fix:**
<img width="1898" height="555" alt="after_allocation" src="https://github.com/user-attachments/assets/60702c72-2e16-4a5f-9b48-213f3c845437" />
<img width="1900" height="535" alt="after" src="https://github.com/user-attachments/assets/15cb27fa-f54b-4e98-94c6-77ae92934c9f" />


```python3
test_17=# select id,private_name,allocation_type,accrual_plan_id from hr_leave_allocation where id = 19;
 id |   private_name   | allocation_type | accrual_plan_id 
----+------------------+-----------------+-----------------
 19 | after allocation | regular         |                
(1 row)
```

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#235568
Forward-Port-Of: odoo/odoo#231253

Before this commit:
-------------------------
When printing the delivery slip of a Purchase Order containing products with
different packaging units of measure (UoM), all units of the same product were
aggregated into a single line, regardless of their packaging type.

Steps to reproduce:
-------------------------
1. Install the 'purchase_stock' module.
2. Create Purchase Order.
3. Add 3 move lines for the same product, each with a different packaging UOM:
      - Product 1 - Pack of 2
      - Product 1 - Pack of 4
      - Product 1 - Pack of 6
4. Confirm the PO and click Receive.
5. Validate the receipt.
6. Go to Actions → Print → Delivery Slip.

Cause of the issue
-------------------------
The aggregation logic in _get_aggregated_properties grouped move lines only by
product, ignoring differences in packaging UoM. As a result, product lines with
different packaging types were incorrectly merged into a single line.

After this commit:
-----------------------
- Delivery slips now correctly separate product lines by packaging UoM and move
  lines for the same product but with different packaging are displayed
  individually.
- This provides a clearer and more accurate delivery report.

Task Id: 4879373

Forward-Port-Of: odoo/odoo#227211

Currently, an error occurs when the user clicks the `Create and Enrich Partner` button.

**Error:**
    `ProgrammingError: can't adapt type 'res.partner'`

This error occurs when the user clicks the `Create and Enrich Partner` button. Then it tries to find or 
create the company using IAP. From here [1], it returns the record as company, and here [2], it writes 
this record into the partner as the parent_id. However, since the parent_id is a record instead of an ID, 
when the system tries to browse the partner by this record [3], the error is raised.

This commit ensures that when writing the parent_id of the partner, the actual ID is used instead 
of the record.

[1]- https://github.com/odoo/odoo/blob/591584268cfcbad54ee675ea62d047c3900ed629/addons/mail_plugin/controllers/mail_plugin.py#L386

[2]- https://github.com/odoo/odoo/blob/591584268cfcbad54ee675ea62d047c3900ed629/addons/mail_plugin/controllers/mail_plugin.py#L52-L53

[3]- https://github.com/odoo/odoo/blob/591584268cfcbad54ee675ea62d047c3900ed629/addons/account/models/partner.py#L801

sentry-6831922000

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

Forward-Port-Of: odoo/odoo#235198

\* : website, web_editor, html_editor

Commit [1]:

Steps to reproduce: replacing image stuck issue when deleted
1. Go to Website > Edit.
2. Add any picture snippet (e.g., Text-Image).
3. Click the 'Replace' button and upload an image.
4. Open the media dialog again and delete the uploaded image.
5. Click the 'Discard' button.
6. Try to save the changes.

Issue:
- The website gets stuck in the same position and does not allow saving.
- In the Python terminal, a missing error warning appears because the image is deleted from both `ir.ui.view` and `ir.attachment`.

Expected behaviour:
- Saving should be allowed with a default image, that is similar to other images.

This commit catch the warning response and replaces the deleted image, allowing the website to save changes without getting stuck.

Commit [2]: resolve traceback when leaving edit mode via browser

Steps to reproduce:
1. Go to Website > Edit.
2. Open the snippet modal and select any snippet.
3. Press the 'Back' button in your browser.
4. A dialog will appear asking to discard changes; click 'OK'.
5. A traceback error occurs, and an empty space appears in the editor.

Issue:
- Previously, a commit addressed a similar scenario, but that time the browser had an event listener bind on hashchange.
- Now, that `hashchange` event of browser has been replaced with `popstate`, which triggers before the 'window' event listener.
- As a result, the editor is left in an unstable state, causing a traceback error.

Solution:
- This commit ensures the 'window' event executes before the browser event.
- It verifies if the editor is open and forces a `skipLoad`, preventing the `route_change` call in the browser.

task-4570164

Forward-Port-Of: odoo/odoo#199193