**Steps to reproduce:**
- Create a combo, set the free and max to 3
- Create the product combo and set it's price to 50
- Go to PoS, order said combo and chose the same product 3 times
- The price is 49.98 instead of 50

**Problem:**
When ordering a combo and taking the same product multiple times, the method to adjust the price does not work as it should. In this case, the method would subtract too much from the total, leading it to be only 49.98 instead of 50.

**Why the fix:**
This happens because when ordering a combo, each line will get it's price_unit from the combo's price divided by the number of lines.
In the case where we have 3 different products, hence 3 different lines, the first two would have a unit_price of 16.67 and the last line will be adjusted as to make it equal to the combo's price, so the last line would be 16.66, making the sum 50. But in the case where there is only one line, the last line is still adjusted, making all the lines 16.66, introducing this error. 

The solution would be to take the line's qty into account when computing how much we should subtract.
Unfortunalty, doing so will, in some cases, introduce a rounding error. If the new unit_price does not round up well (like in this case where it is 16.666668 before rounding and 16.67 after), the rounding will cause a difference between what's shown in the frontend and what's written on the lines in the backend, as the lines are rounded up again before being saved to the backend.

The introduced solution is to split the lines, and each have a quantity of 1. With this solution, we can have a different price_unit for each line, which resolves our problem, as the first two lines will have 16.67 and the last one will have 16.66 as price_unit. 
This is how it was done up until version 18.0, showing every line with a quantity of 1 instead of grouping them.
As the grouped lines are now single, some rounding with taxes might differ from what it was before, which is why a test was altered.

opw-4931215

Forward-Port-Of: odoo/odoo#221189

**Step to reproduce:**
1. Install `sale_management`
2. Open any email template (e.g., Sale: Order Confirmation).
3. Add an attachment to it
4. Create a Sale Order, confirm it, and click "Send by Email".
5. In the mail composer, remove the template attachment

**Issue:**
- The removed attachment is deleted from the database (`ir.attachment`). Consequently, the attachment is permanently removed from the source Email Template and will not appear in future emails.

**Cause:**
- The `onFileRemove` function in `MailComposerAttachmentList` calls the `unlink` method of the `attachmentUploadService` for every file removed, without considering the existing template attachment.

**Solution:**
1. Update `mailComposerAttachmentList` to include `res_model` in `relatedFields` so it is fetched from the server.
2. In `onFileRemove`, check the `res_model` of the attachment.
3. If the `res_model` is not "mail.compose.message", skip the database deletion (unlink)
   and only remove it from the composer view.

opw-5163679

Forward-Port-Of: odoo/odoo#248272
Forward-Port-Of: odoo/odoo#238692

Before this commit: when formatting partially a link, the link is split
at the selection and formatted. This causes duplicated links.

After this commit: we consider links are unsplittable, thus formatting
on links will wrap the selected part in a <font> tag.


commit 2: 
[FIX] html_editor: solve infinite loop of links with color class
Before this commit: we have a fix https://github.com/odoo/odoo/commit/96bc421d30f34a8bfc10dde93c2f283809a8a3e3
which to be able to remove the style classes in the link element

After this commit: We don't consider the style class in the link element
as `hasColor`, because the style classes come from the template code,
which is hard-coded xml. Removing them, the user won't be able to add it
back. For example, on a product page, edit the `Terms and conditions`
link, do nothing and save, the muted color is forced removed.

Note that another fix https://github.com/odoo/odoo/commit/f5fc55f19f89041c8391ff81b127ffce0898f89f is also
removed cause it was a fix for https://github.com/odoo/odoo/commit/96bc421d30f34a8bfc10dde93c2f283809a8a3e3.
The tests belonging to https://github.com/odoo/odoo/commit/96bc421d30f34a8bfc10dde93c2f283809a8a3e3 are
adapted, and those of https://github.com/odoo/odoo/commit/f5fc55f19f89041c8391ff81b127ffce0898f89f are kept
as future safeguards of list coloring.


commit 3:
[FIX] html_editor: extra check on targetnode when splitting blocks
Before this commit: we only check if the current block to be split is
splittable, but not the target node.

After this commit: if the current block is splittable but the current
target node is not, we won't split the block but insert a <br>


commit 4:
[FIX] html_editor: properly fill inlineAncestors when formatting
Before this commit: when the parent node of the current node is
unsplittable, the `inlineAncestors` stays empty.

After this commit: we handle this case and push the parent node in the
list when the parent node is fully selected. We also add a fully
selected predicate in link_plugin for the case when the selection
includes all the content (except for zws) of a non-button link


task-5244810


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

Steps to reproduce:
-------------------
1. Install l10n_ch_hr_payroll.
2. Switch to a Swiss company and create a new employee.
3. Create a new internal user with Payroll Officer/Manager access.
4. Log in as that user, create a contract, and click on "One-time payments".

Issue:
---------
A Traceback with AccessError:
```You are not allowed to access 'Action Window' (ir.actions.act_window) records.```

Cause:
----------
https://github.com/odoo/enterprise/blob/9e39b4b85fcb9f6ed5b21b942796b76b8a6eefdb/l10n_ch_hr_payroll_elm_transmission/models/hr_contract.py#L195
The code attempts to call `.read()` on an `ir.actions.act_window` record.
Standard users typically do not have read access to window action records,
resulting in an **AccessError** even if they have rights to the payroll data.

Solution:
-------------
Use [_for_xml_id](https://github.com/odoo/odoo/blob/93bd4d018d815b5f98d1eaaac3ae613aefbdba56/odoo/addons/base/models/ir_actions.py#L187) to return action content for the provided xml id
in a safe way by doing [sudo](https://github.com/odoo/odoo/blob/93bd4d018d815b5f98d1eaaac3ae613aefbdba56/odoo/addons/base/models/ir_actions.py#L205) internally to bypass the access restriction.

opw-5491467

Forward-Port-Of: odoo/enterprise#106598

Steps to produce:
---
- Install `accountant` and `l10n_mx` modules.
- Switch to Mexican company.
- In Settings, under `Authorized Certification Provider (PAC)`, set PAC to `Solución Factible`.
- Create new invoice > set customer to `INMOBILIARIA CVA`, payment way to `Efectivo` and product as `Large Meeting table` > confirm the invoice.
- Mark the invoice as global.
- Register the payment.
- Create a credit note and confirm it.
- Click Send(make sure CFDI is checked) and check the generated XML.

Issue:
---
- The CFDI XML sets the `Descripcion` field to the default value `Devoluciones, descuentos o bonificaciones`.

Solution:
---
- Preserve the original line description for CFDI refunds instead of forcing
  the generic label.
- For POS refunds, continue using the generic label.
- This aligns with the fix introduced in 19.0([here]).

Before:
---
<img width="519" height="60" alt="image" src="https://github.com/user-attachments/assets/75066bdb-5fba-4959-bf16-8b2953bc40d5" />

After:
---
<img width="615" height="56" alt="image" src="https://github.com/user-attachments/assets/bd93d0af-957f-47fc-b65c-3ec16c4b8f10" />



[here]: https://github.com/odoo/enterprise/pull/97681/changes/515410ec45541e6c07f892a094bb0aa57f479436
**Backport of https://github.com/odoo/enterprise/pull/97681**

opw-5870052
---

Forward-Port-Of: odoo/enterprise#107739
Forward-Port-Of: odoo/enterprise#107367

An improvement in September (PR #95207) began removing accents from names in documents sent to the SAT, in order to comply with their own practices.

In recent months, it has become clear that the SAT does accept accents sometimes. First with umlauts on the `ü` in October (PR #96043), then all umlauts in February (PR #106557). As this PR has found another accepted accented character `É`, it may be necessary to undo the original improvment entirely.

The [Anexo 20 Guía de llenado de los comprobantes fiscales digitales por Internet](http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/Anexo_20_Guia_de_llenado_CFDI.pdf), pg 17, indicates that accented characters are maintained in legal names. At least, `Í` is allowed. At this point in time I only added the exception for `É`.

Steps to reproduce are [on the ticket](https://www.odoo.com/mail/message/999357619), as it requires a real person's tax information.

[opw-5915515](https://www.odoo.com/odoo/project.task/5915515)

Forward-Port-Of: odoo/enterprise#107677