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

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" />

Forward-Port-Of: odoo/odoo#234967