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

Some getters are (too) tied with the evaluation and sometimes take the liberty to throw evaluation-related errors.
This can only work if the said getter is called exclusively in the within the context of the evaluation (which has a splendid try/catch statement to this effect).

Issues start to appear when we start using the said getters outside the evaluation and this is what happens.

Since https://github.com/odoo/o-spreadsheet/issues/6083, we call the getter `getPivotCellFromPosition` which in specific cases call `getCompanyCurrencyFormat` and the latter will throw errors when starting and RPC. However, its effect was hidden by the sortcut added in https://github.com/odoo/odoo/pull/151725.

The effect could only be seen in a version history action where we did not provide a default currency to the model config.

This commit fixes the symptom but not the original cause: having getters that throw and are not handled in the components life-cycle. Such getters should probably disappear in a future refactoring.

Task-5187293

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#232985

Step to reproduce:
- open crm and add a property tags field in a lead
- add that tags in few leads
- go to list view and group by that property tags field
- search for a lead (keep groupby as it is)

Observation:
- we receive a traceback
```
 File "/home/odoo/odoo/codebase/odoo/saas-18.4/addons/web/models/models.py", line 396, in web_read_group
    self._open_groups(
  File "/home/odoo/odoo/codebase/odoo/saas-18.4/addons/web/models/models.py", line 537, in _open_groups
    info_opening['value']: info_opening
TypeError: unhashable type: 'list'
```

Cause:
- `formatter_property_tags` returns a list in case of tags field.
https://github.com/odoo/odoo/blob/5186fd202373a67f56688c234fcde15cc1997721/addons/web/models/models.py#L1176
- these values are used as a key for dict in `_open_groups`, hence only hashable values are allowed; list is not hashable
https://github.com/odoo/odoo/blob/5186fd202373a67f56688c234fcde15cc1997721/addons/web/models/models.py#L536-L539
Fix:
- cast the list to tuple

opw-5188961

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

Forward-Port-Of: odoo/odoo#234091