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.