**Steps to reproduce:**

1. Install the Accounting module.
2. For partner X, create minimum 90 invoices for `See more/Load more` option into page.
3. In the partner form view, click the Customer Statement smart button.
4. Change the Report Type from Customer Statement to Follow-Up Report.
5. In the report, click `See more` in the dropdown → traceback occurs.

**NOTE**
-  You can easily create invoices using this cron job to generate 90 invoices.
```py
for i in range(90):
    invoice = env['account.move'].create({
        'move_type': 'out_invoice',
        'partner_id': 10,
        'company_id': env.company.id,
        'invoice_line_ids': [(0, 0, {
            'product_id': 16,
            'quantity': 1,
            'price_unit': 100.0,
        })],
    })
    invoice.action_post()
```

 **Issue:** 

`UncaughtPromiseError > OwlError
Uncaught Promise > Got duplicate key in t-foreach: ~account.report~17|~res.partner~42|Due~~
Occured`
- A traceback occurs due to a duplicate key error.

 **Cause:** https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/account_reports/static/src/components/account_report/account_report.xml#L72-L73

- In account_report.xml component uses line.id as a key.
<img width="781" height="176" alt="image" src="https://github.com/user-attachments/assets/57bf36ea-6890-45ef-8414-5522d71ece7b" />

- When expanding `See more` headings like `Overdue` are rendered again with the same ID causing a duplicate key error.
<img width="754" height="194" alt="image" src="https://github.com/user-attachments/assets/0eba65e0-0bf2-4f64-a997-27a25e5de5fe" />


**Solution:**
- Use the `line_index` instead of `line.id` as the key, ensuring a unique key for every line and preventing the traceback.

**opw - 5083894**

Forward-Port-Of: odoo/enterprise#95103

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/87b774dfa [REL] 19.0.4 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/c84edcb45 [FIX] Sort: Allow to sort array formula that do not spread [Task: 5033192](https://www.odoo.com/odoo/2328/tasks/5033192)
https://github.com/odoo/o-spreadsheet/commit/0e823e20a [FIX] Carousel: the sidepanel cogwheel has a weird look [Task: 5090177](https://www.odoo.com/odoo/2328/tasks/5090177)
https://github.com/odoo/o-spreadsheet/commit/b2aec82f2 [FIX] charts: truncate radar chart labels correctly [Task: 5078858](https://www.odoo.com/odoo/2328/tasks/5078858)
https://github.com/odoo/o-spreadsheet/commit/b1f21db41 [FIX] carousel: missing color for empty carousel header [Task: 5082459](https://www.odoo.com/odoo/2328/tasks/5082459)
https://github.com/odoo/o-spreadsheet/commit/13482eefd [IMP] test: improve `expect.toHaveStyle` jest matcher [Task: 5059476](https://www.odoo.com/odoo/2328/tasks/5059476)

Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya <rmbh@odoo.com>
Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>

Currently, an error occurs when the operation type (CO) is "Nota Débito que referencia una factura electrónica" and, after confirmation, the user attempts to send the mail.

**Steps to Reproduce:**
- Install Accounting and l10n_co_dian modules.
- Switch company to "CO Company".
- Create new customer invoice. (e.g;  Operation Type (CO) = Nota Débito que referencia una factura electrónica)
- Click on "Send" button. Ensure DIAN is selected in template and then send it.
- Error occurs.

**Error:**
AttributeError - 'bool' object has no attribute 'isoformat'

**Cause:**
The issue happens because debit_origin_id is not set, which makes reference_invoice equal to None, leading to an error. - [1]

In pervious versions, the operation type could not be modified because it was read-only field. From saas-18.4, it became a stored field. Therefore, without debit note, the operation type cannot be changed directly. In this case, the condition at [2] fails, and the method returns None.

**Fix:**
This commit ensures that a value is only returned if a reference invoice exists; otherwise, it returns None.

[1] - https://github.com/odoo/enterprise/blob/8c0217e4e38903783ab7d70ca3eec1c1e3de03de/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L730
[2] - https://github.com/odoo/enterprise/blob/b67a58ffd70952a06b7dd56a54782c433ff673fb/l10n_co_dian/models/account_edi_xml_ubl_dian.py#L1495-L1496

sentry-6810908763

Forward-Port-Of: odoo/enterprise#92714

**Issue**
When importing an XML invoice of document type TD01, it is incorrectly assigned type TD05 after processing.

**Steps to Reproduce**
1. Install Accounting, l10n_it and l10n_it_edi
2. Go to Accounting > Vendors > Vendor Bills
3. Upload an XML invoice with TD01 as the document type
4. Upon confirming the bill, observe that the document type is incorrectly set to TD05

**Root Cause**
The document type matching logic fails to assign TD01 because the uploaded invoice has move_type = in_invoice, while TD01 was only configured to match out_invoice. https://github.com/odoo-dev/odoo/blob/7436e8cee2f605c6d5d559cb410e7a3dc8f372b9/addons/l10n_it_edi/models/account_move.py#L886-L891

**Fix**
According to Italian e-invoicing specifications, TD01 applies to both sales and purchase invoices ("Fatture di vendita" and "Fatture d’acquisto"). To reflect this, in_invoice is now added to the list of supported move_types for TD01, allowing correct detection during XML import.

opw-4931438

Forward-Port-Of: odoo/odoo#219310

*: test_import_export

### Steps to reproduce:

- Go to Sales/Prodcuts/Pricelists
- Create a new pricelist with a rule with a set Valid Period
- Export that record adding the Pricelist Rule/Start Date (item_ids/date_start) as XLSX format
- Delete the record and test the import the XLSX file
#### Uncaught Promise:
> Invalid props for component 'ImportDataColumnError' :'resultNames' is undefined (should be a array)

### Cause of the Issue:

The issue is raised by the error message:
https://github.com/odoo/odoo/blob/32bdff8bc603a03038d3f9e38463809883319305/addons/base_import/models/base_import.py#L1428-L1432
which is not properly handled by the `ImportDataColumnError` component. However, in the present situation, the issue is just that this error message itself should not be raised in the first place.

#### Details:

Since commit 630b2683d3aad203b0bbf7d2d63b88cd4d3bd9d7, date and datetime formatted cells in spreadsheets are no longer Char field. Instead, they are imported as date and datetime objects. This was intended to allow importing columns with mixed encodings (e.g., some values stored as strings, others as dates in the spreadsheet).

However, a side effect of this change is that if a char-type field contains values that a spreadsheet interprets as dates or datetimes, the import fails. For example, an account move name "21/12/2025" may be interpreted as a date. Attempting to perform a join on this string expected value causes a traceback here: https://github.com/odoo/odoo/blob/32bdff8bc603a03038d3f9e38463809883319305/addons/base_import/models/base_import.py#L1628-L1632

To address this discrepancy, commit 91dca74b3e395c8ee410db18784990ba3a6a7e6e introduced a check raising an error if the imported field type is not appropriate to carry a `date/datetime` value.

This fix has two major issues:

1) It still does not handle the above use case correctly—it remains impossible to import "21/12/2025" as a record name. 
2) (The present issue) It does not properly check the type of related fields. For example, a field like "company_id/partner_id/membership_start" is not considered as an allowed date field. The current check on allowed date fields being overly simplistic:
https://github.com/odoo/odoo/blob/32bdff8bc603a03038d3f9e38463809883319305/addons/base_import/models/base_import.py#L1416-L1421

### Fix:

We propose reverting commit 91dca74b3e395c8ee410db18784990ba3a6a7e6e. And instead of recursively computing the related model and the appropriate types of related fields (including property-type relational fields), we will simply stringify values when they are written into char-like fields (e.g., char or text).

Note: this may also require an adjustment in master for the html type.

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

Forward-Port-Of: odoo/odoo#226807

### [FIX] html_builder, website: pass `isPreviewing` to action with colors

With the commit 4448303436fd2d5afe235263e13a9d5daa2d14e1, the `apply`
method of actions should receive an argument `isPreviewing`. This has
not been done for `BuilderColorPicker`.

This commit adds the argument `isPreviewing` when calling `apply` in
`BuilderColoPicker`.

task-4367641

### [FIX] html_builder, *: make options with BuilderMany2One previewable

*: web, website

With the initial [website builder refactor], the options based on
`BuilderMany2One` were not previewable (they were in the previous
builder).

This commit brings back that behaviour. To do so it adds props to
`SelectMenu` and options to `Navigator` to receive the information
needed for the preview

Steps to reproduce:
- On `/blog`, open website builder
- Click on the author of a blog post
- In the sidebar, click on "Contact" to open the dropdown
- Hover other authors than the current one
- Bug: the hovered author is not previewed in the dom
  (like in was in the previous builder)

[website builder refactor]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2
task-4367641

Forward-Port-Of: odoo/odoo#223369

Issue before this commit:
=========================
Currently, when opening the Inventory Valuation menu without setting a Valuation Account in the settings, the system raises the error: `Cannot read properties of undefined (reading 'display_name').`

Steps to Reproduce:
=========================
- Install the account and stock_account modules.
- Switch to another company where the default Valuation Account is not set.
- Create a warehouse and a product with a cost.
- Create and validate a receipt for that product.
- Open the Inventory Valuation menu → traceback occurs.

Cause of the issue:
=========================
In this [PR](https://github.com/odoo/odoo/pull/224479), a new valuation report was added. At the [mentioned line](https://github.com/odoo/odoo/pull/224479/files#diff-8afed36c6f80919b83630d39c78510289ec8fecc632735d26824a84a517a1b7dR60), it's assumes the account always exists and attempts to access display_name directly, leading to the error.

With This Commit:
=========================
We ensure that display_name is only accessed if the account exists, preventing the traceback.