Steps to reproduce:
-------------------
1. Install l10n_ch_hr_payroll_elm_transmission.
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#107628
Forward-Port-Of: odoo/enterprise#106598

This recent commit:
odoo/enterprise@d223f826eaafa3189846b555af16b240f91936ba

changed the formula for `account_financial_report_line_ch_290_a_balance` from:
```py
[('account_id.code', '>=', '290'), ('account_id.code', '<', '2991'), ('account_id.account_type', '!=', 'equity_unaffected')]
```
to:
```py
[('account_id.code', '>=', '290'), ('account_id.code', '<', '2970')]
```
The main goal of the commit was to remove the unaffected earnings account from the CH reports. While doing so, the formula was also modified by replacing `account_id.code = 2991` with `account_id.code = 2970`.

However, since the condition uses the `<` operator, the account with `code = 2970` is not taken into account. Account `2970` is the last account that should be considered before `Annual profit or annual loss`. see:
https://github.com/odoo/odoo/blob/19.0/addons/l10n_ch/data/template/account.account-ch.csv#L106

Ticket [link](https://www.odoo.com/odoo/project.task/5387092)
opw-5387092

Forward-Port-Of: odoo/enterprise#102247

The grouped tax reports are broken if an invoice is created with 2 lines on 2 different income accounts.


[A previous commit](https://github.com/odoo/odoo/commit/48d60151254045768d5aac1b29c5acf84b70cef2) modified the query responsible for the construction of the grouped reports. It only keeps the base lines of type entry which have a balance of the same sign as the tax line. Yet in our case, the CABA move is of type 'entry'. It has only one tax line with a positive amount because the taxes amounts on each line are added. But the balance of the negative line is negative. So the query will only consider the positive line hence the error.

So now, the logic is only considering lines with the same sign to avoid entries where the invoice lines and the refund lines are both there. This is why it only checks for moves of type 'entry'.

We also ignore the check for CABA moves, i.e. moves where `tax_cash_basis_origin_move_id` is defined.


Steps to reproduce:
- Activate Cash Basis in the Settings
- Create a tax based on payment
- Create an invoice with two lines:
   - One with a negative amount, an income account and the created tax
   - One with a positive amount big enough to compensate the previous line, a different income account and the same tax
- Confirm
- Click "Pay", validate the payment
- In the Dashboard > Bank journal > Create a reconciliation of the amount of the invoice
- Reconcile it with the invoice
- Accounting > Reporting > Tax Return
- Select "Group By: Account tax"

Ticket [link](https://www.odoo.com/odoo/project.task/5089790)
opw-5089790

Forward-Port-Of: odoo/odoo#249099
Forward-Port-Of: odoo/odoo#239081

The grouped tax reports are broken if an invoice is created with 2 lines on 2 different income accounts.

[A previous commit](https://github.com/odoo/odoo/commit/48d60151254045768d5aac1b29c5acf84b70cef2) modified the query responsible for the construction of the grouped reports. It only keeps the baselines of type 'entry' which have a balance of the same sign as the tax line.

But in our case, the CABA move is of type 'entry'. It has only one tax line with a positive amount because the taxes amounts on each line are added. But the balance of the negative line is negative. So the query will only consider the positive line hence the error.

So now, the logic of the only considering lines with the same sign is to avoid entries where the invoice lines and the refund lines are both there. This is why it only checks for moves of type 'entry'.

We also ignore the check for CABA moves, i.e. moves where `tax_cash_basis_origin_move_id` is defined.

Steps to reproduce:
- Activate Cash Basis in the Settings
- Create a tax based on payment
- Create an invoice with two lines:
	- One with a negative amount, an income account and the created tax
	- One with a positive amount big enough to compensate the previous line, a different income account and the same tax
- Confirm
- Click "Pay", validate the payment
- In the Dashboard > Bank journal > Create a reconciliation of the amount of the invoice
- Reconcile it with the invoice
- Accounting > Reporting > Tax Return
- Select "Group By: Account tax"

Community PR: odoo/odoo#239081

Ticket [link](https://www.odoo.com/odoo/project.task/5089790)
opw-5089790

Forward-Port-Of: odoo/enterprise#107707
Forward-Port-Of: odoo/enterprise#101601

Various improvements to avoid non-linear growth of returned values when iterating over prefetches.  Traversing a relational field introduces a duplication factor in the returned values.

`records |= more` is syntactic sugar for `records = records | more`, which does not modify the recordset in place but makes one from scratch.  Therefore the time complexity is not `O(len(more))` but `O(len(records) + len(more))`, which is what makes it quadratic when used in a loop.

Since refactor in https://github.com/odoo/odoo/pull/229057, this quadratic complexity is introduced in the prefetching, too.

Changes:
- Keep same prefetch when accessing a single key as when iterating over a recordset. Small gain and more consistent results.
- When iterating over prefetches, deduplicate at source. Without this, the overhead of the generator can be huge for each returned value, since the same value might be returned many times.

In less trivial cases (like traversing two relational fields and making unions with it), the time speedup is several orders of magnitude.

Description
-----------
Getting an `hr.version` from an `offer` during simulation is done in
a savepoint, preceded and followed with flushing of the environment
and some post-cleanup. This is verbose and error-prone, as it's done
at each call site of `hr.contract.salary.offer._get_version` and
`hr.version._generate_salary_simulation_payslip` (or any other
future method that may require such a savepoint). These methods have a
comment that mentions *requiring* a savepoint to be called, but
nothing is enforcing it, so a bug due to oversight is bound to
happen. Context keys are also injected a bit everywhere like
`salary_simulation` and `tracking_disable`, without much consistency,
and adding to the visual clutter.

This commit introduces a little context manager called
`hr_version_context` that manages the creation of the savepoint, the
setup and teardown necessary, and the setting of the keys in the
context.
It's accompanied by a decorator `@requires_hr_version_context` that
will fail if the caller didn't use `hr_version_context` before
invoking the marked method.

This ensures:

- Correct creation of the savepoint and its related pre-/post-operations
- Apply context keys consistently
- Ensure methods that require such setup *cannot* be called without it.

Forward-Port-Of: odoo/enterprise#103187

According to the Mexican Social Security Law, when an employee's total monthly earnings (including bonuses and commissions) are equal to or less than the monthly minimum wage (l10n_mx_daily_min_wage * 365 / 12), they are exempt from social security contributions and income tax, also they lost the subsidy benefit.

- The next rules are zeroed out when the gross salary is equal or less  than the minimum wage:
  - IMSS_EMPLOYEE: IMSS Total (Employee)
  - ISR: ISR (Income Tax)
  - SUBSIDY: Used Subsidy
- IMSS_EMPLOYEE and ISR are omitted from the generated XML.
- As the ISR is zero, the `totalDeducciones` attribute on the `nomina12:Nomina` node should be removed.
- The SUBSIDY should be present in the `SubsidioCausado` attribute on the `nomina12:SubsidioAlEmpleo` node, but the `Importe` attribute on the `nomina12:OtroPago` node should be 0.0.

This change requires updates to existing standard tests, as some previous test cases used amounts lower than the minimum wage.

target: 19.0
task-5226971

Forward-Port-Of: odoo/enterprise#104668

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

Forward-Port-Of: odoo/odoo#249294
Forward-Port-Of: odoo/odoo#241871