Under some conditions, it is currently not possible to render the preview of
some layouts

To reproduce the issue:
(Need `l10n_din5008`)
1. Open Settings more times than the number of companies in the database
   - (We actually need to increase the psql sequence of its table...)
2. Configure your document layout
   - Layout: DIN 5008
3. Click "Preview Document"

Error: an error is displayed: "Missing record: Record does not exist or has
been deleted. (Record: res.company(4,), User: 2)"

When clicking on _Preview Document_, we are actually requesting
`/report/pdf/web.preview_externalreport/4`
Where we have both the report name and the `docids` (equal to `4` in the above
example). Since we are calling it from the `res.config.settings`, we provide
the doc IDs with the ID of the `res.config.settings`. However, the report is
based on the `res.company` model:
https://github.com/odoo/odoo/blob/2f64f909d2f20cc8c0a8e95ba7d17348b9b015e6/addons/base_setup/views/res_config_settings_views.xml#L90
https://github.com/odoo/odoo/blob/e602fc2279e85b66c9983741df5d84fab42a3c44/addons/web/views/report_templates.xml#L1006-L1010
As a consequence, the mechanism will try to render the report using the
company with ID equal to the ID of the config settings, which does not make
sense. This is the reason why, at some point, it can lead to a `Missing
Record` error.

That said, the case is working well on previous versions because we were
defining a global `o` variable before rendering the template, cf for
instance on Odoo 19, L896:
https://github.com/odoo/odoo/blob/1c2e17718e6f2a11d93585f0ea3ba3abee5a4a41/addons/web/views/report_templates.xml#L893-L897
Thanks to that variable, DIN 5008 side, we ignore the `docs`, cf here for
instance:
https://github.com/odoo/odoo/blob/dae4fd0000080ba6395b370e25d3f13f1becd74e/addons/l10n_din5008/report/din5008_report.xml#L96

On Odoo 19.1+, this global variable has been removed by [1]. This commit is
actually the result of a script (cf its description). Since the script
hasn't detected the use of `o`, it moved its declaration inside the previous
`t-call`, L829:
https://github.com/odoo/odoo/blob/e602fc2279e85b66c9983741df5d84fab42a3c44/addons/web/views/report_templates.xml#L827-L830
This was a mistake since the global variable is sometimes used. Long story
short, the script didn't see the dynamic `t-call` inside the template of
`web.external_layout`:
https://github.com/odoo/odoo/blob/e602fc2279e85b66c9983741df5d84fab42a3c44/addons/web/views/report_templates.xml#L758-L761

We have therefore decided to revert this part of the commit and apply the
same logic to its siblings `preview_internalreport` and `preview_layout_report`

[1] https://github.com/odoo/odoo/commit/b7ec60d68c6ee23f7684960e33e5bd6290c9d829

OPW-5951003

Forward-Port-Of: odoo/odoo#254198

Steps to reproduce:
- Enable "Expiration Dates" in Inventory settings
- Create a storable product "P1"
  - Add 10 units with "Lot 1"
- Enable expiration dates on product P1
- Add 10 units with "Lot 2" and set an expiration date
- Create a delivery for 10 units of P1
  - Mark as "To Do"
  - Open the move line

-> "Lot 1" is automatically reserved

- Change the lot from "Lot 1" to "Lot 2" -> The expiration date is not updated automatically

- Save and reopen the move line -> The expiration date is correctly set

- Change again to "Lot 1"
- Save and reopen the move line -> The expiration date is not reset and incorrectly keeps the value from "Lot 2"

Cause:
The expiration date was only computed based on `lot_id`, ignoring the
`quant_id` used during reservation. Additionally, the value was not
reset when switching to a lot without an expiration date.

Solution:
- Add `quant_id` to the compute dependencies
- Compute the expiration date based on `quant_id.lot_id`
- Explicitly set an expiration date to today when the
use_expiration_date product is set to True and the lot doesn't have an
expiration date.

Result:
The expiration date is now correctly updated and cleared when changing lots on stock move lines.

opw-5999294

Forward-Port-Of: odoo/odoo#254610

### Steps to reproduce:

- Create a product that is not track inventory (`is_storable = False`)
- Set its cost to 50$ and put it in an avco perpetual valuation category
- Create and receive a purchase order for 10 units
- Set the product as track inventory (`is_storable = True`)
- Inventory > Reporting > Stock
- Click on the `unit cost` of your product line
#### > This opens the `stock.avco.report` according to which the total value of your stock is 500$ and the total quantity is 10 units even though do not have any unit in stock.

### Expected behavior:

The line of the receipt should have been counter balanced by an inventory adjustment line to resets the valuation at the same time as the product has been set to `is_storable`

### Cause of the issue:

There is currently no mechanism to counter balance the stock that should have been present in internal locations if the moves done had been processed with a storable product.

opw-5472902

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

Forward-Port-Of: odoo/odoo#255557
Forward-Port-Of: odoo/odoo#254380

Currently, if a user selects an exchange difference account as a write-off but then
decides to keep the invoice open, the system still fully reconciles the invoice.

Steps to reproduce:
- Create an invoice in foreign currency
- Click 'Register Payment'
- Select company currency
- Change the amount to a lower one
- Select 'Mark as fully paid'
- Add the exchange difference loss/gain account as write off account
- Select 'Keep open'
- Click 'Create payment'

Issue:
Even though the user selected the option to create a partial payment and keep
the invoice open, it is totally reconciled with a difference booked in the
selected exchange account.

Analysis:
This occurs because the use of the exchange account as write off account
trigger a specific flow used in localization where a writeoff is not allowed.
Once the payment registration process is ongoing, the system does not check
that user kept the same choice on how to handle the payment difference.

opw-5468052

Forward-Port-Of: odoo/odoo#254479
Forward-Port-Of: odoo/odoo#251965

*= im_livechat, portal, test_discuss_full

**Steps to reproduce:**

• Install the mail_group module
• Open Discuss
• Go to the History tab
• Add a reaction on a message that has model `mail.group`  
• Throws an error

The error occurs because the `mail.group` model does not implement the `_get_allowed_access_params()` method, which is invoked during the process here. Actually, the "add reaction" button should not be shown on messages whose model
does not inherit from mail.thread.
https://github.com/odoo/odoo/blob/d12c1e07727f9b04cd2be2e7dac1ec3af49cb637/addons/mail/models/mail_message.py#L579

Desired behavior after PR is merged:

This PR fixes the issue by hiding the "add reaction" button on messages with
models that don’t inherit from mail.thread, such as mail.group.

enterprise: https://github.com/odoo/enterprise/pull/111271
Task-5098050

[Reference](https://github.com/user-attachments/assets/aa2c4251-fd1f-4734-a62c-9fc80dd5f587)

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

Forward-Port-Of: odoo/odoo#255950
Forward-Port-Of: odoo/odoo#218615

[Issue]
1) When a POS downpayment is created, it doesn't set the account.move.lines.is_downpayment = true. So, no POS invoice line was being marked as a down payment. 2) When preparing to create the invoice lines for the sales order, it never checks the original POS Invoice lines for down payments.

[Fix]
1) When creating the invoice lines for the down payment through the POS, set the 'is_downpayment' based on if the product is the POS's down payment product. 2) Create _prepare_invoice_lin,e then filter through the POS invoice lines for downpayments and then set them accordingly.

Steps to Replicate:
1) User creates a Sales Order for a customer,
2) Transfers it to the POS, and the customer makes a down payment. 3) The user creates an invoice on the Sales order to pay the remainder of the bill 4) The account Id on the account.move.line does not match the original account on the POS invoice for the original account.move.line

Video Demo of the issue:
https://drive.google.com/file/d/1FszCJRUF-cCgg8otxu1jj1kmdKauwTGL/view?usp=drive_link

Video Demo of Solution:
https://drive.google.com/file/d/1yrYBdQZFw7YeKxsgsQQx5gHkuGER-7BN/view?usp=drive_link

Forward-Port-Of: odoo/odoo#249180

Since its introduction (https://github.com/odoo/odoo/pull/76734), the "mail.catchall.domain.allowed" system parameter is normally sanitized by `_sanitize_allowed_domains` when using `set_param`.

But the method is not run when the system parameter is created manually, for example through the UI, because the current conditional logic is not triggered for write and create call.

This can be an issue if for example the use submits this value: "domain1.com, domain2.com,domain3.com"

The comma seperated list will only be split by ',', meaning that the second element is " domain2.com" (space character in front). As such, that domain will not be used as expected, since most flows using that data will end up comparing "domain2.com" vs " domain2.com", and not considering it a match.

Before this fix:
Create new record in System parameters with
key = "mail.catchall.domain.allowed"
value = "domain1.com, domain2.com,domain3.com"
-> after save, value == "domain1.com, domain2.com,domain3.com"

After this fix:
-> after save, value == "domain1.com,domain2.com,domain3.com"

OPW-5505414

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

Forward-Port-Of: odoo/odoo#255969
Forward-Port-Of: odoo/odoo#244279

Currently, if a user selects an exchange difference account as a write-off but then
decides to keep the invoice open, the system still fully reconciles the invoice.

Steps to reproduce:
- Create an invoice in foreign currency
- Click 'Register Payment'
- Select company currency
- Change the amount to a lower one
- Select 'Mark as fully paid'
- Add the exchange difference loss/gain account as write off account
- Select 'Keep open'
- Click 'Create payment'

Issue:
Even though the user selected the option to create a partial payment and keep
the invoice open, it is totally reconciled with a difference booked in the
selected exchange account.

Analysis:
This occurs because the use of the exchange account as write off account
trigger a specific flow used in localization where a writeoff is not allowed.
Once the payment registration process is ongoing, the system does not check
that user kept the same choice on how to handle the payment difference.

opw-5468052

Forward-Port-Of: odoo/odoo#254479
Forward-Port-Of: odoo/odoo#251965

Problem:
Sometimes pressing space in content containing a symbol pattern creates the symbol even when the space is not placed directly before it.

Cause:
`leftLeafOnlyNotBlockPath` sums the `spaceOffset` of all non-block leaf nodes, then performs a substring on the whole block containing those leafs.

In this case, the file box contains a `span` with `d-flex`, which is considered a block. Therefore, the file box text content length is not included in the `spaceOffset` calculation.

However, we later call `substring` on the `textContent` of the `closestBlock`, which includes the file box content. This leads to an incorrect `spaceOffset`, effectively skipping the file box text.

This can happen by chance when the `substring` returns the file box text content with `"-->"` immediately after it, making it the last character and triggering symbol creation.

Solution:
When computing the `substring`, consider only the `textContent` of the leaf nodes traversed while calculating `spaceOffset`. This ensures the offset matches the actual traversed content and prevents accidental symbol generation.

Steps to reproduce:
- Use the same HTML structure as in the test.
- Place the selection as in the test case.
- Press space.
- Observe that a symbol is incorrectly created.

task-6004954

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

After https://github.com/odoo/odoo/pull/240547 was merged, an issue appeared with the snippets that could also be dropped as inner content. Instead of only having the dropzones for sections, all dropzones were activated, meaning that snippets such as countdown would sometimes be dropped as inner content.

Steps to reproduce the issue:
- Go to Website
- Go to Edit mode
- From an empty website, click on the snippet group "Content"
- Select the countdown
=> The countdown was dropped in the footer instead of the main

To fix this issue, this commit restores the missing filter (removed when the new builder was added). However, since the drag and drop was updated to only display dropzones of the "active" element, there is no need to filter the dropzones within #website_cookies_bar. Finally, the filter is no longer based on the s_popup snippet, as the drag and drop mechanic was moved outside of the website module.

This commit also partially reverts the commit 5cb4f5c, since it made the tour fail with the changes of this PR (s_banner snippets can no longer be dropped inside of the s_table_of_content)

The tour testing the Countdown was updated since it did not fail prior to saas-19.2, because it was not precise enough.

Related to task-5428387

Forward-Port-Of: odoo/odoo#254724
Forward-Port-Of: odoo/odoo#250613

Steps to reproduce:
- Enable analytic distribution in Accounting settings
- Create a storable product "P1":
  - Routes: MTO + Buy
  - Vendor: add any supplier
- Create a Sale Order:
  - Add 1 unit of P1
  - Set any analytic distribution
- Confirm the Sale Order

Result:
A Purchase Order is created, but the analytic distribution is not propagated
to the purchase order line.

Problem:
When the Sale Order is confirmed, `_action_launch_stock_rule()` is triggered.
It creates and confirms the corresponding stock move with values from the
sale order line.

Since the product uses the MTO route, the procurement rule is executed.
The rule prepares procurement values from the stock move, but the analytic
distribution is not included in these values:

https://github.com/odoo/odoo/blob/18.0/addons/stock/models/stock_move.py#L1539

Later, `_run_buy` is triggered. It uses the procurement values coming from the
stock move to find an existing purchase order line candidate or to create a
new one. Because the analytic distribution is missing from the values, the
created (or matched) purchase order line does not contain the analytic
distribution:

https://github.com/odoo/odoo/blob/621a93b7b723999d943f1c4da78547763498c008/addons/purchase_stock/models/stock_rule.py#L113

Solution:
Propagate the analytic distribution from the sale order line through the stock
move so it can be included in the procurement values and correctly applied to
the purchase order line.

opw-5936971

Forward-Port-Of: odoo/odoo#254933
Forward-Port-Of: odoo/odoo#252292

[Issue]
1) When a POS downpayment is created, it doesn't set the account.move.lines.is_downpayment = true. So, no POS invoice line was being marked as a down payment. 2) When preparing to create the invoice lines for the sales order, it never checks the original POS Invoice lines for down payments.

[Fix]
1) When creating the invoice lines for the down payment through the POS, set the 'is_downpayment' based on if the product is the POS's down payment product. 2) Create _prepare_invoice_lin,e then filter through the POS invoice lines for downpayments and then set them accordingly.

Steps to Replicate:
1) User creates a Sales Order for a customer,
2) Transfers it to the POS, and the customer makes a down payment. 3) The user creates an invoice on the Sales order to pay the remainder of the bill 4) The account Id on the account.move.line does not match the original account on the POS invoice for the original account.move.line

Video Demo of the issue:
https://drive.google.com/file/d/1FszCJRUF-cCgg8otxu1jj1kmdKauwTGL/view?usp=drive_link

Video Demo of Solution:
https://drive.google.com/file/d/1yrYBdQZFw7YeKxsgsQQx5gHkuGER-7BN/view?usp=drive_link

Forward-Port-Of: odoo/odoo#249180

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

**Steps to reproduce:**
- Install Accounting and Expenses
- Create a Branch company (e.g. Branch)
- In company selector, select both Branch (as main) and its parent

- In Bank journal settings, make sure that there is an outstanding payment account for "Manual Payment"

- Create an employee in Branch
- Create an expense:
  * Category: [any] (e.g. [EXP_GEN] Expenses)
  * Total: [anything] (e.g. 100.00)
  * Employee: [the created employee]
  * Paid By: company
  * Company: Branch
- Create Report
- Submit to Manager
- Approve

**Issue:**
A UserError is raised because it tries to create a payment in Branch linked to a journal entry in the parent company.

**Cause:**
The payment is initialized with the company of the expense but not the related journal entry.


**(A similar issue happens with an expense paid by the employee when generating the bill upon approval of the expense sheet)**

opw-6007859



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

### Issue before this commit:
When creating a credit note using “Reverse and create invoice”, the generated invoice loses the Source field. While the original invoice correctly displays the source, the new invoice created after reversal does not, leading to missing information in the report.

### Steps to reproduce the issue:
1. Create a sales order for product A
2. Deliver product A
3. Create invoice
4. Create credit note by clicking on "Reverse and create invoice"
5. The new invoice correctly remains linked to the Sales order
6. However, the source document disapear on the PDF

### Cause of the issue:
In the reversal flow, the new invoice is created using copy_data() without explicitly preserving the invoice_origin field. As a result, the newly created invoice does not inherit the source information from the original invoice, even though it is still logically linked.

### Reason to introduce the fix:
To ensure consistency between invoices and preserve important traceability information, the invoice_origin field must be propagated to the new invoice created during the reversal process. This guarantees that the Source is correctly displayed in the PDF.

opw-6034574

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