**Description of the issue this PR addresses:**
------------------------------------------------

When editing a message via the ArrowUp shortcut, any previously mentioned channels (e.g., `#general`) were not restored in the composer. This happened because the logic to restore mentions was only applied in the `onClick()` handler of the Edit message action.

**Current behavior before PR:**
---------------------------------

- Editing a message using ArrowUp does not restore mentioned channels  
- Editing via the Edit message action still works correctly  

**Desired behavior after PR is merged:**
-----------------------------------------

- Mentioned channels are restored when entering edit mode via ArrowUp  
- Behavior is consistent with editing through the Edit message action
- No mentions are lost in any edit scenario  

**Important: This PR should only be merged for versions saas-18.2, saas-18.3, and saas-18.4.**

**Backport of https://github.com/odoo/odoo/pull/229546/commits/5878e398615596adcf09eef8acbbe5aa739918f3**

**Task:** 5133698

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

Forward-Port-Of: odoo/odoo#234995
Forward-Port-Of: odoo/odoo#231192

Currently, when creating a DHL shipment with an export declaration that includes a customer reference, there is a misspelling of the field 'recipientReference' as 'recepientReference'. This causes validation errors when communicating with the DHL API.

In addition, the datetime format used for the planned shipping date and time does not conform to the expected format specified by DHL.

Steps to reproduce spelling issue:
1. Create a Sales Order with a customer reference and a deliverable product.
2. Validate the SO.
3. Go to the delivery, select DHL as carrier, and confirm. → Error: Validation error #/content/exportDeclaration: extraneous key
  [recepientReference] is not permitted.

Steps to reproduce datetime issue:
1. Create a delivery using the DHL carrier.
2. Confirm the delivery.
3. Return the delivery.
4. Click "Print Return Label". → Error: Bad request #/plannedShippingDateAndTime is not well formatted
  (expected format: '2010-02-11T17:10:09 GMT+01:00').

Official DHL documentation:
https://developer.dhl.com/sites/default/files/2025-11/dpdhl-express-api-3.1.1_swagger.yaml

opw-5024363

Forward-Port-Of: odoo/enterprise#98981

Before this PR,
The breadcrumbs flickered when navigating between livechat sessions.
This occurred because the `FormController` ([@web/views/form/form_controller](https://github.com/odoo/odoo/blob/saas-18.3/addons/mail/static/src/core/web/discuss_patch.js#L16-L23)) 
updated the breadcrumb title inside the `onRendered` hook and set it to 
`this.model.root.data.display_name` which is `undefined`, the `Discuss` component 
also updated the breadcrumb title in a `useEffect` hook. ([@mail/code/web/discuss_patch.js](https://github.com/odoo/odoo/blob/saas-18.3/addons/mail/static/src/core/web/discuss_patch.js#L16-L23))
  
The two updates conflicted: the onRendered hook first set the title to 
“Unnamed,” and then the useEffect hook replaced it with the correct title, 
causing a brief flicker. Additionally, when navigating to another session with 
the same thread.displayName, the useEffect hook did not trigger (since its 
dependency did not change), but onRendered still ran, causing the breadcrumb 
to remain “Unnamed”.
    
This PR fixes the issue by introducing a `LivechatFormController` which
updates the breadcrumbs when channel is fetched in store.
    
task-4671251

Before:
![breadcrumbs-before](https://github.com/user-attachments/assets/ae8e6943-07ce-4b4a-a3e6-4c027afe32c3)

After:
![breadcrumbs-after](https://github.com/user-attachments/assets/f26e4d9e-66b0-4209-9ff2-938688c6042f)

task-4671251

Forward-Port-Of: odoo/odoo#233167

Some other test adds a fiscal position with tax mapping. This creates 2 problems

1. The new taxes have a tag, which means we evaluate the right hand of

https://github.com/odoo/enterprise/blob/8d3fe30c627eada1186c15480876fb2e8f7ddb59/delivery_shiprocket/models/shiprocket_request.py#L239

However, since l10n_in is not installed,

`tax.env.ref(f"l10n_in.tax_tag_{gst}gst", False)`

does not return anything (False is not a fallback)

https://github.com/odoo/odoo/blob/1e96a3d127e8f521d3027f7110026ae84e11ed5e/odoo/api.py#L588

So we end up looking for `None` in `tax_tag_ids`, which leads us to compare the `_name` properties, see

https://github.com/odoo/odoo/blob/1e96a3d127e8f521d3027f7110026ae84e11ed5e/odoo/models.py#L6545-L6558

2. The test added in 4d5df93 was assuming the default company 15% tax, which was not always true

Solution
-----

1. Provide a fallback for the `ref` lookup
2. Force a 15% tax in the test

-----
runbot-232692

Forward-Port-Of: odoo/enterprise#99027
Forward-Port-Of: odoo/enterprise#97998

**Steps to reproduce:**
- Add some folders
- Create a new company
- Assign some folders to the new company
- Archive the company
- Click on Documents app
- AccessError is raised when opening it

**Issue:**
The issue seems to be related to caching issue on the field `type` when fetching the documents with `search_panel_select_range` and going through `_compute_display_name`:
`folders = accessible_records.filtered(lambda d: d.type == 'folder')`

This error was quite inconsistent and might be related to the cache missing some prefetched data on a record it shouldn't have been able to read. There is a need to ensure only the folders available to the user are able to be fetched.

**Fix:**
Added the `type` field in the `search_panel_fields` but this might not be needed if the issue comes from elsewhere.

For now the issue was mitigated by explicitly checking for the user companies in the domain of the searchs, but it needs to be checked as this behavior might break other flows.

opw-4931278

Forward-Port-Of: odoo/enterprise#99043
Forward-Port-Of: odoo/enterprise#96817

Versions
--------
- 18.0+

Steps
-----
1. Have a product attribute with variant creation set to never;
2. have product using only this attribute, with only a single value;
3. open website editor on /shop;
4. enable add-to-cart button & save;
5. use button on the aforementioned product at least twice.

Issue
-----
Each time the product gets added, a new line is created.

Cause
-----
Because there's only a single value, the product configurator doesn't pop up by default when adding the product to the cart. Without the configurator pop-up, the `_cart_update` method doesn't receive any `no_variant_attribute_value_ids`, which are used find a matching line if the product template has any `no_variant` attribute.

Solution
--------
Instead of checking `product.product_tmpl._has_no_variant_attributes()`, to see if we should attempt to match `no_variant_attribute_value_ids`, check if the added product has any `no_variant` attributes that have more than one value or are optional (multi-checkbox). If not, a `no_variant` product behaves the same as a single-variant product.

opw-5093175
opw-5137351

Forward-Port-Of: odoo/odoo#234958
Forward-Port-Of: odoo/odoo#233452

Step to reproduce:
- open crm and add a property tags field in a lead
- add that tags in few leads
- go to list view and group by that property tags field
- search for a lead (keep groupby as it is)

Observation:
- we receive a traceback
```
 File "/home/odoo/odoo/codebase/odoo/saas-18.4/addons/web/models/models.py", line 396, in web_read_group
    self._open_groups(
  File "/home/odoo/odoo/codebase/odoo/saas-18.4/addons/web/models/models.py", line 537, in _open_groups
    info_opening['value']: info_opening
TypeError: unhashable type: 'list'
```

Cause:
- `formatter_property_tags` returns a list in case of tags field.
https://github.com/odoo/odoo/blob/5186fd202373a67f56688c234fcde15cc1997721/addons/web/models/models.py#L1176
- these values are used as a key for dict in `_open_groups`, hence only hashable values are allowed; list is not hashable
https://github.com/odoo/odoo/blob/5186fd202373a67f56688c234fcde15cc1997721/addons/web/models/models.py#L536-L539
Fix:
- cast the list to tuple

opw-5188961

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

There’s no constraint preventing duplicate `ir.default` records. When setting a default using `self.env['ir.default'].set()`, it searches for an existing one, but if more than one match is found, accessing `default.json_value` raises a singleton error.

This fix makes sure the search only picks one record, avoiding that crash.

Before fix:
```py
self: res.users(1,)
>>> company = self.company_id
>>> company
res.company(1,)
>>> self.env['ir.default'].create({'field_id': 4540, 'company_id': company.id, 'json_value': 7})
ir.default(9,)
>>> self.env['ir.default'].set('res.partner', 'property_account_receivable_id', 7, company_id=company.id)
Traceback (most recent call last):
  File "/home/odoo/odoo/odoo/odoo/orm/models.py", line 5630, in ensure_one
    _id, = self._ids
    ^^^^
ValueError: too many values to unpack (expected 1)

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<console>", line 1, in <module>
  File "/home/odoo/odoo/odoo/odoo/addons/base/models/ir_default.py", line 107, in set
    if default.json_value != json_value:
       ^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo/odoo/odoo/orm/fields.py", line 1670, in __get__
    record.ensure_one()
  File "/home/odoo/odoo/odoo/odoo/orm/models.py", line 5633, in ensure_one
    raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: ir.default(4, 9)
```

After fix:
```py
self: res.users(1,)
>>> company = self.company_id
>>> company
res.company(1,)
>>> self.env['ir.default'].create({'field_id': 4540, 'company_id': company.id, 'json_value': 7})
ir.default(10,)
>>> self.env['ir.default'].set('res.partner', 'property_account_receivable_id', 7, company_id=company.id)
True
```

opw-5228419


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

Forward-Port-Of: odoo/odoo#234944
Forward-Port-Of: odoo/odoo#234893

**Description of the issue/feature this PR addresses**:
This pr is to avoid duplicated taxes when the demo data is installed.

**Steps to reproduce**:
1. Install l10n_ar_withholding module with demo data.
2. Take position in "(AR) Responsable Inscripto" company.
3. Check the taxes created on "Invoicing > Configuration > Accounting > Taxes".
4. Delete the filter "Sale or Purchase".
5. Add custom filter: Argentina Withholding Payment Tax type (l10n_ar_withholding_payment_type) is in ["supplier", "customer"].
6. You will see that there are duplicated taxes (duplicated names) with suffix (Copy).

**Current behavior before PR**:
Duplicated taxes are created when demo data is installed.
<img width="1597" height="795" alt="image" src="https://github.com/user-attachments/assets/51b65037-bb89-4ec7-8adf-21636b68e405" />

**Desired behavior after PR is merged**:
No duplicated taxes are created when demo data is installed.

_Task latam side_: 1360.
_Task Adhoc side_: 57627.


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

Forward-Port-Of: odoo/odoo#226992