Problem:
When running the MPS report on a large number of production schedules, if the associated number of stock moves is high, the _get_moves_and_date method can cause a memory error.

Solution:
We will fetch only the necessary fields to reduce queries and memory usage and set prefetch_fields=False to further reduce memory usage.

Benchmarks:
Run locally on a dupe of customer's db.
Time/queries measured by requests to /get_mps_view_state Memory measured using memray on method get_production_schedule_view_state()

<table>
   <tr>
      <th rowspan="2"># of Production Schedules</th>
      <th colspan="3">Before</th>
	   <th colspan="3">After</th>
   </tr>
   <tr>
      <th>Time</th>
      <th># of Queries</th>
	   <th>Memory usage</th>
      <th>Time</th>
      <th># of Queries</th>
	   <th>Memory usage</th>
   </tr>
   <tr>
      <td>20</td>
      <td>22.846s</td>
      <td>1,379</td>
      <td>882.0MB</td>
      <td>8.046s</td>
      <td>1,180</td>
      <td>103.4MB</td>
   </tr>
   <tr>
      <td>300</td>
      <td>41.098s</td>
      <td>6,297</td>
      <td>1.0GB</td>
      <td>43.694s</td>
      <td>5,732</td>
      <td>363.5MB</td>
   </tr>
	<tr>
      <td>1000</td>
      <td>N/A (MemoryError)</td>
      <td>N/A (MemoryError)</td>
      <td>>2GB</td>
      <td>88.416s</td>
      <td>22,629</td>
      <td>1.1GB</td>
   </tr>
</table>
Average memory usage reduction: 75%


opw-5225472

Forward-Port-Of: odoo/enterprise#106392

There is an issue with the history dialog in very specific scenarios where a
toggle (or any similar block) is involved, resulting in an incorrect
"comparison" being displayed.

How to reproduce:
- create a new Knowledge article, and replace the title with a toggle block
- in the "content" section of the toggle, write a word, e.g. "word" in the
  paragraph.
- exactly below the toggle block, write the exact same word ("word") in a
  paragraph.
- save the article
- open the version history
- click on the oldest entry (there should be 2 of them), and click "view
  comparison"

Issue:
- the paragraph below the toggle is not shown.

Technical explanation:
- There is an incomplete constraint in `generate_comparison`, which is related
  to a trade-off (see `test_replace_nested_divs`), which was supposed to ignore
  identical successive `opening` tags. However, it also ignores `closing` tags,
  which it shouldn't do (it causes this issue).
- This issue produces invalid html which could also cause owl crashes (in
  addition to the incorrect comparison), if embedded components were present in
  the invalid html part.

task-5933410

Forward-Port-Of: odoo/odoo#249184

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

CronJobs timed_out_counter is not getting reset when reaching the CONSECUTIVE_TIMEOUT_FOR_FAILURE due to a transaction rollback. This commit introduces a fix to ensure only records with an actual exception tuple pass through in method: 'method_direct_trigger'.

Description of the issue/feature this PR addresses:
When a cron job reaches the timeout threshold (timed_out_counter >= 3), method_direct_trigger crashes because the ListLogHandler filter matches log records that have exc_info = None. But the original filter only checked hasattr(lr, 'exc_info') which is true for all LogRecord objects. This caused a TypeError when attempting to unpack exc_info (None) on the next line, which rolled back the transaction and prevented timed_out_counter from being reset.

Current behavior before PR:
Clicking "Run Manually" on a timed-out cron (timed_out_counter >= 3) raises TypeError: cannot unpack non-iterable NoneType object, rolling back the transaction. The timed_out_counter is never reset, leaving the cron permanently stuck.

Desired behavior after PR is merged:
The filter correctly skips log records where exc_info is None (i.e., non-exception errors like timeouts). method_direct_trigger returns True, the transaction commits, and timed_out_counter is properly reset to 0.


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

Forward-Port-Of: odoo/odoo#248978

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

Reinstalling the appointment module fails during mail template validation.

### Reproduction Steps

1. Install the `appointment_hr_recruitment` module.
2. Uninstall `appointment`.
3. Reinstall `appointment`.

→ A template parsing error appears.

### Cause

The global `request.env` is bound to the registry active at the start of the request. When reinstalling a module, this registry becomes stale and does not include the models being re-added.

During installation, the `mail.template` model performs a test render to validate its XML data. One of the templates calls `_get_interview_invite_url`, which invokes a controller that looks up the `appointment.type` model using `request.env`.

Because the registry is stale and does not contain this model, the lookup raises a KeyError and the installation fails.

### Fix Rationale

Skip invite URL generation when `install_mode` is set to avoid using the stale `request.env`.

opw-5898780

Forward-Port-Of: odoo/enterprise#107650

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

Steps to reproduce:
- Install `account` module
- Taxes > open any existing tax > Set `factor_percent(%)` of repartition lines to negative(eg: [Image](https://www.awesomescreenshot.com/image/58851592?key=ce0017bb467a583ad020f33d21d4d8ba))
- Create a Invoice and add tax in move line and save

Traceback:
`IndexError: list index out of range`

We are getting `factors` as empty because `target_factors` from `_add_accounting_data_to_base_line_tax_details` is empty.

This happens because, in `tax_reps`, we are filtering repartition lines with a `factor` greater than `0`. However, when the `factor` is less than `0`, `tax_reps` becomes empty, which leads to the error.

We are reverting this PR: https://github.com/odoo/odoo/pull/234334 because it prevents the validation error from being raised when there is a negative value in the repartition lines.


[factors]: https://github.com/odoo/odoo/blob/de056cc784a3bbe2575fd3c9e81ca62e73c362d4/addons/account/models/account_tax.py#L1641

[tax_reps]: https://github.com/odoo/odoo/blob/de056cc784a3bbe2575fd3c9e81ca62e73c362d4/addons/account/models/account_tax.py#L2429-L2431

sentry-7102210210

Forward-Port-Of: odoo/odoo#249220

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