**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

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

Steps to reproduce the bug:
- Create a storable product "P1" and "P2" with vendor "azure interior"
- for P2 subcontracting BoM referencing "azure interior" as subcontractor and component "C1"
- Create a receipt for partner "azure interior" including 1 unit of P1 and 1 unit of P2
- Validate the receipt
- Create a return for both P1 and P2

Problem:
A picking is created with destination location set to the subcontracting location for both products,
instead of setting the partner location only for subcontracted products.

Solution:
Ensure only the move line for subcontracted products uses the subcontracting destination location,
while other returned products go back to the supplier location.

When the `picking_id.partner_id`` is changed, it triggers a write on the
picking, which in turn triggers a write on its moves, but only on the
ones that are not scrapped.

However, since the `scrapped`` field is a stored computed field, and as
it hasn't been accessed before, it needs to be computed. And because
its computation depends on `location_dest_id`, that field also needs
to be recomputed. as a result, the `location_dest_id`` of the moves that
we manually set may be changed unexpectedly.

Therefore, in the `_create_return`` function, we check that the
picking’s `partner_id` is different from the moves’ partner_id before
updating it, to avoid unnecessary writes and the chain of recomputations
that could alter our values.

Resetting the picking’s partner_id based on the move’s partner_id could
actually be removed in master, as it serves no real purpose,
the move.partner_id itself is already derived from the picking’s
partner_id. We just keep it in stable versions to avoid any unexpected
behavior changes.

opw-5208289

Forward-Port-Of: odoo/odoo#234521

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

Before this commit when a module was updated all ir.asset records were
reset to their defined `active` state, if defined.
This causes assets related to old snippet versions to be made inactive
even if those old snippet versions are used inside existing pages.

It used to work when the activation of assets was made through view
inheritance because when views are defined through a `<template>` tag,
the `active` attribute is in fact ignored during updates since [1],
except for new records since [2].

This commit introduces an `<asset>` tag in the XML import format.
It is an alias of `<record ... model="ir.asset">` with the additional
feature that it avoids taking the `active` field into account during
updates for existing `ir_asset` records, just like `<template>` if the
`active` field is mentioned as attribute of the tag.
We then rely on the `website_disable_unused_snippets_assets` cron to
properly disable any unused asset at a later stage (note that the bug
being fixed here was mitigated by the fact that cron also re-enabled
assets which were disabled by mistake... but that might happen only a
few days later).

Another approach was to overload `_load_records_write` in `base`'s
`ir_asset.py` to avoid taking the `active` field into account when
updating records:
```py
    def _load_records_write(self, values):
        values.pop('active', None)
        super()._load_records_write(values)
```
But this is not as stable because it changes the way `ir.asset` records
are imported when the `<record>` tag is used. In the end we chose to be
consistent and do exactly the same as `<template>`, as this also allows
more and should be entirely stable.

[1]: https://github.com/odoo/odoo/commit/2d296cb77922d33be2dc45b900191fac34bda429#diff-175c28787c272a219b9275f79262a48af9aa029e718f45077fd609737559e84eR803-R804
[2]: https://github.com/odoo/odoo/commit/f1c70d4cc943ac4eb81a85a9dc005de34cd2060a#diff-175c28787c272a219b9275f79262a48af9aa029e718f45077fd609737559e84eR801-R804

task-2963840

(Follow-up of https://github.com/odoo/upgrade/pull/3829)

Forward-Port-Of: odoo/odoo#233402
Forward-Port-Of: odoo/odoo#104836

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

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

Following commits odoo/odoo@d37d908 and odoo/enterprise@901b8ea, the tooltip cleanup logic disposes elements in `website_sale_renting`, and when the same logic runs again  in `payment`, it tries to dispose them a second time, causing  a null element error.

Steps to reproduce:
1. Install `website_sale_renting`
2. Install a demo payment method
3. Go to the shop, add any product to the cart, proceed to payment
4. Click the "Edit" button on the website → observe the error

```js
web.assets_frontend_lazy.min.js:3912 TypeError: Cannot read properties of null
(reading 'closest') at Tooltip.dispose (web.assets_frontend_lazy.min.js:2710:70)
    at PaymentForm.<anonymous> (web.assets_frontend_…zy.min.js:8282:1450)
    at Colibri.destroyInteraction (web.assets_frontend_lazy.min.js:6472:68)
    at Colibri.destroy (web.assets_frontend_lazy.min.js:6524:55)
    at InteractionService.stopInteractions (web.assets_frontend_lazy.min.js:6584:162)
    at InteractionService.stopInteractions (web.assets_frontend_lazy.min.js:6625:907)
    at stop (website.assets_insid…rame.min.js:137:290)
    at HTMLDocument.<anonymous> (website.assets_insid…rame.min.js:153:450)
    at WebsiteBuilderClientAction.onEditPage (web.assets_web.min.js:22215:55)
```
- Restrict tooltip handling to elements with the .o_rental_info_message class to ensure only the intended elements are selected.

- This fix ensures tooltip cleanup is performed safely without re-disposing already disposed elements.

Forward-Port-Of: odoo/enterprise#98748

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

[FIX] hr_work_entry: fix work entries not being regenerated on attendance modification

Steps to reproduce:
- In Attendance, create, modify or delete an attendance
- In Payroll, go to the work entries tab
	- If creating an attendance, work entries with the previous and current
attendance duration will be displayed
	- If modifying an attendance, changing the duration would not create
a new work entry nor modify the existing one(s)
	- If deleting an attendance, the work entry would be deleted even if
there were other attendances on the same day

Reason:
- For creation, the method creating work entries from attendances had a strict
inequality, which caused the check to never trigger.
- For modification, nothing was done to regenerate the work entry after
editing the duration.
- For deletion, the method archived work entries regardless of whether or
not there were other attendances in the day.

How it was fixed:
- For creation, changed the strict inequalities to inequalities to allow the
check for work entries to be made
- For modification, if the check in or check out dates are changed, triggers
the regeneration of linked worked entries
- For deletion, the work entry is only deleted when no attendances are left, and then
 regenerate work entries to match the new total attendance duration

Task ID: 5116353

Forward-Port-Of: odoo/enterprise#96635

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

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

steps to reproduce:
-------------------
1. Install sales
2. Enable Product Variants and Pricelists under Sales > Configuration
3. Open a product variant and create a pricelist rule
4. Save it

issue:
-----
The pricelist rules are not saved.

cause:
------
The field `pricelist_rule_ids` on `product.product` is a non-stored One2many. https://github.com/odoo/odoo/blob/b1041951d436b4b6adc90d8b8dd7b8c88cc69a46/addons/product/models/product_product.py#L62-L68 In the ORM, such fields are handled in the else part of [write_real()](https://github.com/odoo/odoo/blob/b1041951d436b4b6adc90d8b8dd7b8c88cc69a46/odoo/orm/fields_relational.py#L1033-L1049), Since this field is non-stored, it has no corresponding column in the database to persist changes. As a result, any updates made to it are lost after saving.

solution:
---------
Add an inverse method to make the field writable.

opw-5097909

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

Forward-Port-Of: odoo/odoo#229521

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

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

Summary of the fixes for the Put/Pack in pack:
- Avoid an error when trying to click on 'Move a Pack' on an unsaved picking.
- Apply putaway rules at with multi-level packages, considering higher-level packages first.
- Consider higher-level packages when checking package routes.
- Updates the picking operation pdf.
- For pickings, no longer display the 'Packages' stat button if no package are set as destination. We keep it for batches however, as it's currently the only way to add entire packs into a batch.
- Be more lenient with the 'Remove' button for packages in a picking.
- Allow to select the right packages as destination in a picking.
- Change priority of move line when using 'Put in Pack', always prioritizing `picked` lines.
- Avoid `Unnamed` packages when creating a new package without a name from a list view.
- Display the parent packages in the 'Pick from' auto-complete.

For more detail about each fix, read the related commit.

Task-5116567

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

Steps to reproduce
------------------

Login to runbot, wait `odoo.http.SESSION_ROTATION_INTERVAL`s (3h) then access any page, then access any bundle using its id (not its `f'{name}-{id}') e.g. `/runbot/bundle/123`. Traceback: cannot use a closed cursor. It occurs when the system tries to save the session.

Traceback, explained
--------------------

1. The previous request session underwent a "soft rotation", its sid changed and it was marked "gc_previous_sessions".
2. The following request matches a route that is website & multilang, it is the case of the runbot bundle route.
3. The session was marked "gc_previous_sessions", it removes *now* the other sessions and removes the mark from the current one, this sets the current session dirty.
4. The request URL is not canonical, `_pre_dispatch` in `http_routing` abords with a redirection to `/runbot/bundle/18.0-123`.
5. The abortion (`werkzeug.exceptions.abort`) is an exception that bubbles up all the way up in the http stack, notably above `_serve_db` where `request.env.cr` is closed.
6. `odoo.http.root.__call__` ultimatelly processes the response received from `_pre_dispatch`: it calls `post_process` which call `_save_session` which sees that the current session is dirty: it attempts to save it.
7. Because there is a `session.uid`, we need to refresh the session token, for that we need an environment and a cursor.
8. Kaboom, the cursor was closed by `_serve_db`.

Problem
-------

When we set/delete items from the session, the changes are only saved in the session object in memory. The modified session is only written once, at the end of the request, if no error occured.

When we save the session, we gotta update the `session_token` value, this token is a SHA over the user's login information: active, email, password, ... and is verified upon loading the session in a future request. Should the user changes its password, a new token would be computed and all the sessions with the old token would become invalid. Should the user uses an old session, he would get redirected to /web/login.

Computing the `session_token` is mandatory when there's a `uid` inside the session, otherwise the session would be invalid. Computing it requires a valid cursor to fetch the user's active, email, password, ...

In our case, the (valid) response contained in `wekzeug.exception.abort` did bubble-up above `_serve_db`: `request.env.cr` is closed.

Solution
--------

Move the exception handling for `werkzeug.exceptions.abort` in both `_serve_nodb` and `_serve_db`. That it is in `_serve_db` makes it possible to call `_post_dispatch` with a cursor and environment that are still alive. This fixes the problem at hand.

With the above fix, comes two sanity things:

The `if session.uid and env` conditional is wrong, it must be only `if session.uid`. When there is a uid stored in the session, updating the `session_token` is mandatory. It MUST crash if `save()` is called for a session with a uid but with no environment.

The `_serve_db` method manages both the request's cursor and the `request.env` attribute. Everytime the cursor is updated (e.g. when changing from a read-only to a read+write one)

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

**Issue:**
Multiple errors occur when processing payroll for "Fully Flexible" employees
and overlapping leave scenarios:

1. ValueError "Expected singleton: hr.work.entry.type(7, 8)" during work entry generation
   when sick leave overlaps with public holiday

**Steps to Reproduce:**
1. Go to the **Employees** app and create a new employee.
   * Set the working hours to **empty (fully flexible)**.
2. Go to **Contracts** and create a new contract.
   * Set the **Work Entry Source** to *Attendance*.
   * Save and make the contract **Running**.
3. Go to **Time Off** → **New**, and create a sick time off for the employee.
   * Example: from **25th to 29th**.
   * Approve the time off.
4. Go to **Configuration** → **Public Holidays**, and create a new public holiday.
   * Example: **27th**, which overlaps with the sick time off.
   * Work Entry Type = **Paid Time Off**.
5. Go to **Payroll** → **Work Entries**.
   * A **traceback** occurs.

**Root Causes:**
- In `_get_interval_leave_work_entry_type()`: Direct access to `interval[2].work_entry_type_id.code` causes singleton violation when overlapping leaves create intervals containing multiple work entry types.

**Fix:**
- Replace direct access to `interval[2].work_entry_type_id.code` with safe recordset slicing `interval[2].work_entry_type_id[:1].code` to prevent singleton violation when interval contains multiple work entry types

This resolves payroll blocking issue for deployments using the
Fully Flexible employee feature, where employees may have
overlapping leave types and no assigned working calendar.

Test : [PR](https://github.com/odoo/enterprise/pull/93902)

opw-4979974

Forward-Port-Of: odoo/odoo#230659
Forward-Port-Of: odoo/odoo#223448

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

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

**Description of the issue/feature this PR addresses:**
Issue: The purchase_price field in sale order lines is not recomputed when changing the pricelist to a different currency after a sales order has been confirmed, cancelled, and set back to quotation state.

This causes incorrect cost calculations and margin reporting when users need to modify the currency/pricelist of a previously confirmed order that was later cancelled and reset to draft.

Affected modules: sale_stock_margin

Versions affected: 16.0, 17.0, 18.0 (confirmed on 18.0)

**Current behavior before PR:**
When a sales order goes through the following workflow:

Create a sales order with a pricelist in USD
Add a product line (e.g., purchase_price shows $100.00 USD)
Confirm the order (stock moves are created)
Cancel the order (stock moves are set to state 'cancel' but remain in move_ids)
Set the order back to quotation state
Change the pricelist to one with a different currency (e.g., EUR)
Result: The purchase_price remains in the original currency (USD) instead of being converted to the new currency (EUR).

Root cause: The _compute_purchase_price() method in sale_stock_margin checks if move_ids exist to determine whether to use stock-based costing or fall back to the standard price from sale_margin. However, cancelled moves are still present in move_ids, causing the method to skip the currency conversion that should happen when no valid (non-cancelled) moves exist.


**Desired behavior after PR is merged:**
After following the same workflow:

Create a sales order with a pricelist in USD
Add a product line (purchase_price shows $100.00 USD)
Confirm the order
Cancel the order
Set the order back to quotation state
Change the pricelist to EUR
Expected result: The purchase_price is automatically recomputed and converted to the new currency (e.g., shows €92.00 EUR based on the exchange rate).

How it works: The method now filters out cancelled stock moves before checking if valued moves exist. If only cancelled moves are present, the computation is delegated to the parent sale_margin module, which properly handles currency conversion using _convert_to_sol_currency().


Video Demostration
From runbot of today (10/21/2025)
https://drive.google.com/file/d/1KExSzOYHAmMc10b3u_Xy5B1nWkkYOBqy/view


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

## The issue

Prior to this commit, the `other` parameter in the `_merge`
method could belong to a different class, not necessarily an
instance of `Intervals`.

https://github.com/odoo/odoo/blob/8c737601327acec1d83e1e5e3c6e66c9fd226339/addons/resource/models/utils.py#L158-L165

The comment indicates that normalization should be enforced; however, there
is no corresponding reference to it within the  `_boundaries` method.

https://github.com/odoo/odoo/blob/8c737601327acec1d83e1e5e3c6e66c9fd226339/addons/resource/models/utils.py#L48-L53

That normalization just happens in the `__init__`.

https://github.com/odoo/odoo/blob/8c737601327acec1d83e1e5e3c6e66c9fd226339/addons/resource/models/utils.py#L117-L132

## Example

For example, in Planning module, we perform operations between
`Intervals` and `WorkIntervals`.

The `WorkIntervals` class behaves differently from `Intervals`:
while `Intervals` uses disjoint closed intervals, `WorkIntervals`
uses disjoint semi-closed intervals.

## Side effects

During these operations, the `_merge` method was not normalizing
the `_items`, which caused inconsistencies and errors (when we are
merging two unormalized intervals `([0, 10], [10, 20])` with an empty
`others`).

## The fix

This commit ensures that the `other` parameter is normalized before
processing the `_merge` operation. The fix ensures that normalized
intervals are always produced after `_merge`, even when unnormalized
intervals are provided as input.

## Real case

That issue has been found in that ticket: 5184291

Forward-Port-Of: odoo/odoo#234352

## The issue

Prior to this commit, the `other` parameter in the `_merge`
method could belong to a different class, not necessarily an
instance of `Intervals`.

https://github.com/odoo/odoo/blob/8c737601327acec1d83e1e5e3c6e66c9fd226339/addons/resource/models/utils.py#L158-L165

The comment indicates that normalization should be enforced; however, there
is no corresponding reference to it within the  `_boundaries` method.

https://github.com/odoo/odoo/blob/8c737601327acec1d83e1e5e3c6e66c9fd226339/addons/resource/models/utils.py#L48-L53

That normalization just happens in the `__init__`.

https://github.com/odoo/odoo/blob/8c737601327acec1d83e1e5e3c6e66c9fd226339/addons/resource/models/utils.py#L117-L132

## Example

For example, in Planning module, we perform operations between
`Intervals` and `WorkIntervals`.

The `WorkIntervals` class behaves differently from `Intervals`:
while `Intervals` uses disjoint closed intervals, `WorkIntervals`
uses disjoint semi-closed intervals.

## Side effects

During these operations, the `_merge` method was not normalizing
the `_items`, which caused inconsistencies and errors (when we are
merging two unormalized intervals `([0, 10], [10, 20])` with an empty
`others`).

## The fix

This commit ensures that the `other` parameter is normalized before
processing the `_merge` operation. The fix ensures that normalized
intervals are always produced after `_merge`, even when unnormalized
intervals are provided as input.

## Real case

That issue has been found in that ticket: 5184291

Before this commit, when using livechat for visitors on mobile devices, click on input would zoom on input of about 115%.

This zoom would hide send button at the very end of composer input, and would force users to pinch-to-unzoom, making the UX quite poor.

This problem happens because mobile devices have an auto-zoom feature that is triggered when font-size is below 16px. The discuss UI is designed with 14px font size (web client font size), and since 14px < 16px, it zooms on input focus to about 115%.

This commit fixes the issue by using a font-size of 16px specifically for livechat visitor on mobile devices, so that this doesn't auto-zoom. Note that this problem doesn't happen on the web client even though this uses a font-size of 14px because it specifically disable the autozoom feature:
https://github.com/odoo/odoo/blob/17.0/addons/web/views/webclient_templates.xml#L250

This solution is not practical for livechat, for which it has to work on any external website.

opw-5229076

Before
<img width="199" height="431" alt="after" src="https://github.com/user-attachments/assets/cc2f8e04-bde7-4eeb-84d5-b2efa2763490" />

After
<img width="199" height="431" alt="before" src="https://github.com/user-attachments/assets/6c6679fc-9c16-40e7-ab6f-21540d20d59d" />