When a report uses 'previous_return_period' date_scope on one of its expressions, if there's no account.return.type linked to that report, the opening of the report crashes. This is a bit stupid, since a return type without periodicity will anyway fallback to the the company's tax periodicity field. When there's no return type, we should simply fallback in the same way.

To reproduce:
- Make a Belgian company, install the CoA and localization
- Manually uninstall l10n_be_reports
- Try opening the tax report

Another message also checked that we couldn't compute this date_scope in case there was more than one return type linked to the report, arguing they have different periodicities, so we can't infer which one to use. However, it they actually shared the same periodicity, that check failed anyway. We refine it to authorize this case, and only raise if they truly have different periodicities.

opw-6022150

Forward-Port-Of: odoo/enterprise#111872
Forward-Port-Of: odoo/enterprise#111796

### Steps to reproduce
------------------
- Install `l10n_ae` module.
- Go to *Settings → Countries* and rename the country "United Arab Emirates" (e.g. change it to "UAE").
- Upgrade the `l10n_ae` module.

### Issue
-----
The file `l10n_ae/data/res.bank.csv` references the country using its name ("United Arab Emirates"). During the module upgrade, the CSV import tries to resolve the country relation using the country name. If the country name has been modified by the user (for example to "UAE"), the lookup fails and the module upgrade crashes with:

```python3
No matching record found for name 'United Arab Emirates' in field 'Country'
```

### Root Cause
----------
Using translatable/display names in CSV data is unreliable, as these values can be customized or translated by users.

### Fix
---
Replace the country name reference with the stable XMLID `base.ae` in `res.bank.csv`.

Using XMLIDs ensures consistent resolution regardless of name changes or translations.

opw-6015302
upg-3950261
tbg-2492

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

### Steps to reproduce
------------------
- Install `l10n_pe` or `l10n_ec` module.
- Go to *Settings → Countries* and rename the country (e.g. "Peru" → "PERÚ",
  "Ecuador" → "ECUADOR").
- Upgrade the module.

### Issue
-----
The files `l10n_pe/data/res.bank.csv` and `l10n_ec/data/res.bank.csv`
reference countries using their names (e.g. "Peru", "Ecuador").

During module upgrade, the CSV import resolves many2one relations using
the country name. If the country name has been modified by the user,
the lookup fails and the module upgrade crashes with:


```python3
2026-03-06 23:48:11,112 27 CRITICAL db_3950261 odoo.service.server: Failed to initialize database `db_3950261`.
Traceback (most recent call last):
  File "/home/odoo/src/odoo/19.0/odoo/service/server.py", line 1510, in preload_registries
    registry = Registry.new(dbname, update_module=update_module, install_modules=config['init'], upgrade_modules=config['update'], reinit_modules=config['reinit'])
  File "/home/odoo/src/odoo/19.0/odoo/tools/func.py", line 88, in locked
    return func(inst, *args, **kwargs)
  File "/home/odoo/src/odoo/19.0/odoo/orm/registry.py", line 199, in new
    load_modules(
  File "/home/odoo/src/odoo/19.0/odoo/modules/loading.py", line 456, in load_modules
    load_module_graph(
  File "/home/odoo/src/odoo/19.0/odoo/modules/loading.py", line 216, in load_module_graph
    load_data(env, idref, mode, kind='data', package=package)
  File "/home/odoo/src/odoo/19.0/odoo/modules/loading.py", line 59, in load_data
    convert_file(env, package.name, filename, idref, mode, noupdate=kind == 'demo')
  File "/home/odoo/src/odoo/19.0/odoo/tools/convert.py", line 689, in convert_file
    convert_csv_import(env, module, pathname, fp.read(), idref, mode, noupdate)
  File "/home/odoo/src/odoo/19.0/odoo/tools/convert.py", line 754, in convert_csv_import
    raise Exception(env._(
Exception: Module loading l10n_pe failed: file l10n_pe/data/res.bank.csv could not be processed:
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'
No matching record found for name 'Peru' in field 'Country'

 select id,name,code from res_country where code='PE'
+-----+----------------------------------------------------------------------+------+
| id  | name                                                                 | code |
|-----+----------------------------------------------------------------------+------|
| 173 | {"de_DE": "Peru", "en_US": "PERÚ", "es_ES": "PERÚ", "es_PE": "Perú"} | PE   |
+-----+----------------------------------------------------------------------+------+
```


### Root Cause
----------
Using translatable/display names in CSV data is not reliable, as these
values can be customized or translated.

### Fix
---
Replace country name references with stable XMLIDs:
- `base.pe` for Peru
- `base.ec` for Ecuador

Using XMLIDs ensures consistent resolution regardless of name changes
or translations.

opw-6015302
upg-3950261
tbg-2492

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#256201
Forward-Port-Of: odoo/odoo#254096

### Steps to Reproduce:

- Create a toggle list and add content.
- Expand the toggle list and insert a code block (e.g.: /code).
- Add multiple lines inside the code block using Enter.
- Refresh the page with the toggle open, content is preserved.
- Close the toggle and refresh then content collapses into one line.

### Description of the issue/feature this PR addresses:

- When the toggle list is closed, the code block is inside `display: none` container. In this state, `innerText` depends on rendered layout and does not preserve newline characters `\n`. As a result, multiline code content is extracted as single line.

### Desired behavior after PR is merged:

- Read html and normalize it into plain text by:
  - Converting `<br>` tags into newline characters.
  - Stripping remaining HTML tags.
  - Decoding HTML entities back to their literal characters.
  - Removing the extra newline introduced by a trailing `<br>`
  - Cleaning up invisible zero-width characters.

task-5909034

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

Forward-Port-Of: odoo/odoo#248391

Currently, an error occurs when a user creates an alias ID.

**Steps to Reproduce:**
 - Install the `hr_recruitment` module.
 - Go to `your current company` and set the `Email Domain` value.
 - Go to `Recruitment` > `Applications` > `By Job Positions`.
 - In `list view`, create or open an existing `Job Position`.
 - In the `Trackers` tab, create a record through “Add a line”.
 - Click the `copy clipboard` button next to the `email` field.

**Error:**
`AttributeError: 'hr.recruitment.source' object has no attribute 'name'`

After [this commit], the dependency of utm.source.mixin was removed, along with the 
source_id field referencing a source. The name field was provided by utm.source.mixin, 
and it is now being accessed in recruitment source, which raises the error [1].

This commit ensures that the system uses the name of source_id, as it has been 
replaced by _rec_name to "source_id".

[this commit]: https://github.com/odoo/odoo/commit/927682ce8f5e6faea0da7216ac1163411f5e83bd

[1]- https://github.com/odoo/odoo/blob/949d368eda3d6f2c9b5fb04ec3a41fa1b2cc90d4/addons/hr_recruitment/models/hr_recruitment_source.py#L42

sentry-7353030705

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

Steps to reproduce:
--------------------------------------
1. Install Time off module
2. Navigate to Time off > Management > Allocations
3. Click on the 'New Group Allocation' button
4. Click on the Time Off Type field to open the selection dropdown.

Observation:
--------------------------------------
Traceback occurs:
```
  File '/home/odoo/odoo/community/odoo/orm/domains.py', line 920, in _raise
    raise error(message % (*args, self.field_expr, self.operator, self.value))
ValueError: Invalid field hr.work.entry.type.company_id in condition ('company_id', 'in', [1, False])
```

Issue:
--------------------------------------
In the commit https://github.com/odoo/odoo/pull/244436/changes/5b9570e4bd4cc0ae7d9a81e33f49dc538ae5acd3 model name changed from `hr.leave.type` to
`hr.work.entry.type`. With this change `company_id` field is removed too. However, the domain on the field still referenced `company_id`, leading to an invalid domain and traceback.

Solution:
--------------------------------------
Remove the company_id condition from the domain since the field no longer exists on `hr.work.entry.type`.

opw-6037286

Before this commit, closing an AI chat window could lead to the following crash:

```js
TypeError: Cannot read properties of undefined (reading '_raw')
```

Steps to reproduce:
- have no chat windows open, cache cleared.
- open DM with demo in chat window from messaging menu, in home menu.
- open AI chat, from systray.
- close the AI chat window. => crash

This happens because when closing the AI chat window, it deletes the AI conversation. By deleting the AI conversation, it removes the conversation from `store.menuThreads`, which is the list of conversations to display in messaging menu. Removal of this conversation in `menuThreads` is done internally through

```js
const index = recordList.indexOf(record);
recordList.splice(index, 1);
```

This is done that way as to reuse custom methods of `RecordList`, especially the `splice()` that is used by many methods that mutate the record list. Internal code of the custom `splice` method does `slice()`, which is used to retrieve some records without mutating the record list.

In practice, these `.slice()` were accidentally mutating the list, because they invoke the `Proxy.getter` of the `RecordList`, and when the list is flagged for `computeOnNeed` / `sortOnNeed`, invoking this `Proxy.getter` would mistakenly enable the `computeInNeed` / `sortInNeed` flags and thus mutate the list, e.g. with a sort, which may change the order of items and mess up the `index` computed in `indexOf()` step.

This is what happens with the chat window. The `menuThreads` looked something like this:

```js
menuThread = ["thread_1", "thread_2", "thread_3"];
```

With the removal of `thread_2`, the `.indexOf()` is `1`, but due to `.slice()` triggering the sort, the list was changed to:

```js
menuThread = ["thread_2", "thread_1", "thread_3"];
```

... And it instead removed `thread_1` but kept `thread_2` in list. This introduce 2 problems:
- `thread_1` is mistakenly removed from relation when it shouldn't
- `thread_2` is kept, but since this is a local id with no actual record in store, `recordList[index]` would return `undefined` as there's no existing record matching this local id.

This commit fixes the issue by improving internal code of record list
methods to avoid accidental triggering of lazy re-compute and
re-sort. The accidental re-compute and re-sort come from invoking
non-implemented array methods on the proxy of record, such as:

- `recordProxy.at()`
- `recordProxy.slice()`

These methods were just used meant to retrieve records from the record list, and they did so by using accessing through `recordProxy`. This approach has the benefit to look good as this is exactly the same as the external API, but it has the unintended side-effect of the re-compute / re-sort of lazy fields. Instead of using these methods, records are retrieved with:

- raw access to get local ids in relation
- convert local ids to raw records through raw access in `store.recordByLocalId`

This approach, while uglier, has the benefit to not accidentally trigger the re-compute / re-sort.

opw-5761279

Forward-Port-Of: odoo/odoo#251769