When the label of a link is fully selected and the user pastes some
text, the link is removed. It was removed even if the link was in a
`contenteditable=false` or was unremovable.

This commit only attempts to remove the link element after checking
these conditions. It also only selects the link in the `before_paste`
handler, and lets the normal paste logic remove it.

Steps to reproduce (after 18.4, where it was noticed):
- Copy some simple text
- Open website builder
- Select completely the label of a menu in the header
- Paste
- Bug: the menu item is removed, and replaced with simple text

Steps to reproduce (in 18.0 and later):
- Open "To-Do" app
- Add a link in the middle of a line of text
- With inspector, edit html to put `contenteditable="false"` on the
  container of the line, and `contenteditable="true"` on the link
- Select completely the label of the link in the document
- Paste some text
- Bug: the link is removed, and the clipboard content is inserted after
  the non editable element

task-5110141

Forward-Port-Of: odoo/odoo#229558
Forward-Port-Of: odoo/odoo#228223

**Steps to reproduce:**
- enable multi-step routes setting.
- navigate to warehouse management/locations create a new location
(the "test location").
- select "internal location" for the location type.
- select WH for the parent location
- navigate to warehouse management/warehouses and select the warehouse
corresponding to WH.
- set the warehouse in 3 steps delivery.
- click on the routes smart button.
- click on the "deliver in 3 steps (pick+pack+ship)" route.
- add a rule, for the action select "push to", for the operation type 
select "internal transfers", for the source location select the "test 
location" you just created and for destination location select "WH/Output".
- save.
- create a storable product and set an on-hand quantity
- create a new sale order for 1 quantity of this product and confirm it
- click on the picking smart button, change the destination location to the
test location and validate
- open the sale order and change the quantity to 3


**Current behavior:**
A new picking is created from stock to packing zone (which is the 
expected behavior) but the quantity is 1 

**Expected behavior:**
The quantity should be 2.
If we only increase the quantity by 1 on the sale order it does not even 
create the new picking

**Cause of the issue:**
The warehouse_id field is invisible in stock.rule form view when the 
action is push. Therefore, the rule is created without a warehouse_id.
Also, moves created from a rule have the same warehouse_id as the rule. 
https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/stock/models/stock_rule.py#L275
So, when we validated our first move (from stock to the test location), 
this created a second move (from test location to output) that does not 
have a warehouse id (because it was created from our own push rule that
we created).
When we update the quantity of the sale ordre line, 
_action_launch_stock_rule calls _get_quantity_procurement to compute 
the current quantity on the moves.
This method then calls _get_outgoing_incoming_moves to get the initial 
move created from the rule. In this case this should return only the 
first move created.
But because the second move does not have a warehouse_id, it's rule.id
is added to triggering_rule_ids.
https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/sale_stock/models/sale_order_line.py#L315-L317
And the move is later added to the outgoing moves that will be returned.
https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/sale_stock/models/sale_order_line.py#L322-L329

So the two moves are returned and the sum of the quantities of the moves
is 2 instead of 1.
https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/sale_stock/models/sale_order_line.py#L292-L294
So the product quantity for the procurement will be 1 (3-2) 
instead of 2 (3-1).
https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/sale_stock/models/sale_order_line.py#L386

opw-5039249

Forward-Port-Of: odoo/odoo#229332
Forward-Port-Of: odoo/odoo#227421

Before this commit, a maximum call stack traceback occurred when accessing the chat tab of the messaging menu on iOS when many chats were present. On chrome and firefox, no traceback occurred, but the menu took a long time to open.

Threads shown in the messaging menu rely on the `menuThreads` store property, which had two issues:
- It was a computed field done on the many side of the relation, while relying on the inverse (thread) side would be much faster.
- The sort function was triggered for each thread inserted or removed from the relation. The sort function is not trivial, and accessing sort fields through the reactive proxy is very slow.

This commit fixes the issue by:
- Updating the `menuThreads` property to use an inverse instead of a complex compute.
- Debouncing the array sort to ensure it is executed only once when the relation is properly filled.

task-4794325

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

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

Steps
-----
1. Enable rental transfers;
2. have a rental product with a kit BoM;
3. create a subscription order in the Rental app;
4. add the rental product;
5. confirm order;
6. validate deliveries;
7. close the subscription.

Issue
-----
Invalid SQL command, cannot return more than was delivered.

Cause
-----
When closing or reopening a subscription, the `_compute_qty_delivered` method gets triggered. By default, these methods required the relevant moves to have the same `product_id` as the sale order line.

For products with kit BoMs, the move's `product_id` is tied to the BoM instead of the final product, leading to `qty_delivered` getting reset reset to 0 on recompute.

This causes an error, as `qty_returned` is non-zero.

Solution
--------
The `qty_delivered` for these lines was set in the `_action_done` method of `stock.move`. By instead moving this logic into a `_compute_qty_delivered` override, any recompute should have the same result, instead of getting reset to 0.

opw-4833280

Forward-Port-Of: odoo/enterprise#96179
Forward-Port-Of: odoo/enterprise#88691

> [VBAL] Supported payment methods inner content (in the header): You can adjust the height, but this moves the elements on the right outside of the screen (can be fixed by zooming/unzooming on the screen but not user friendly): https://drive.google.com/file/d/1J0Vp050kDzx_jnPVfWyHxy6GpQ6GvpBX/view?usp=drive_link


### [FIX] website: re-adapt extra menu on size changes of menu and navbar

When the size available or needed for the the top menu changes (for
other reasons than a window resize), the menus were not auto-hidden.
They were auto-hidden only if the window changes size.

If the user is editing the website and increase the width of some
element in the header, it may overflow. The overflow disappears only
once the user changes the size of the window (which causes some menu to
be hidden again).

This commit fixes that by replacing the listener for a window `resize`
event by a `ResizeObserver` that observe the sizes of the navbar, the
menu and the menu's siblings.

Steps to reproduce:
- Open website builder
- Add text in the header until it gets too large
- Bug: the last menu is not moved to the dropdown to make more space
  available

task-4367641

### [FIX] website: move selection with menu when auto-hiding menus

When some menu are moved to be hidden in the dropdown, if the selection
is inside a moved menu, it was lost.

This commit fixes that by opening the dropdown and moving the selection
if it is in a menu moved to the dropdown

Steps to reproduce:
- Open website builder
- Add text in the label of a menu until it is moved to the dropdown
- Bug: the selection is lost, keep writing does not write anywhere

task-4367641

### [FIX] website: remove selection in dropdown when it closes

When the user has the selection inside a dropdown that closes, the
selection was kept. If the toolbar was shown on the selection, then used
to stays floating where the selection used to be.

This commits listen for the closing of the dropdown to remove the
selection if it was in the dropdown.

Steps to reproduce:
- Open website builder
- Click on the user's name to open the dropdown
- Select some text in the dropdown (the toolbar should appear)
- Press "esc" (the dropdown should close)
- Bug: the toolbar is left hanging where the selection used to be

task-4367641

Versions
--------
- 17.0+

Steps
-----
1. Set currency rounding of EUR to 1.0;
2. use the currency on a website pricelist;
3. go to a product page in /shop;
4. open the url in a new session.

Issue
-----
From the editor, the price gets displayed as expected, with no decimals. In the new session, the price gets displayed with two decimals.

Cause
-----
The `_priceToStr` method used, always uses a `precision` of 2, except in editor mode when it will retrieve a different value from a hidden `.decimal_precision` element.

Solution
--------
Add the website's currency precision to `combination_info` via the controller, and use this value in `_priceToStr`.

For the product configurator, store the currency precision in the `.js_price_total` element's dataset.

Also insert the precision in the `.oe_price` element's dataset, allowing it to be used as a fallback in case the configurator template isn't up to date.

opw-4996878

Forward-Port-Of: odoo/odoo#229416
Forward-Port-Of: odoo/odoo#224429

**PROBLEM**
Insuring a delivery using the dhl carrier don't work. It doesn't affect the estimated rate of the delivery, and the shipment created when validating the delivery order isn't insured.

**STEP TO REPRODUCE**
1. Install the `delivery_dhl_rest` and the `l10n_be` modules (we will use the be demo company).
2. Set the insurance percentage of the dhl be delivery method to 100%, and set the region to Europe (the demo data is incorrect), and activate the debug (click the "No Debug" smart button to activate the log of requests).
3. Switch to the be company.
5. Create a sale order, with a customer located in Belgium, and add shipping using the dhl method.
6. Go to the delivery order, and validate it.
7. Go to settings/Technical/Logging and look at the rating_request and shipment_request, notice there is no information about insurance.

**CAUSE**
We don't send any info about insurance in the api requests.

**FIX**
Computing and sending the insured amount, only if the insurance percentage is not null.
If the package can't be insured between the origin and the destination, a error message will be displayed when updating the delivery price.

**TESTS PROBLEM/FIX**
The localization of `your_company` was not recognized by DHL, leading to the DHL api returning a 0 delivery price.
Switching the localization to Eghezee, Rue du Laid Burniat 5 fixes this.
Assertion regarding the delivery price were restored.

The picking date could sometimes be refused by DHL (stop working after arround 4/5 PM).
Changing the picking date to, two day after, at noon works.

`test_01_dhl_basic_be_domestic_flow` was modified to also test domestic shipment insurance in addition of the basic flow.
Some code in it was refactor into inner function to avoid boilerplate.

Adding `INSURED_RATE_MOCK_RESPONSE` to mock response in test_01.

opw-4989281

Forward-Port-Of: odoo/enterprise#93105

**Issue description:**
The logic introduced in #127196 adds default taxes from "other" companies to products created without a specific company.
However, because child companies (branches) share taxes with their parent company, when creating a new product using the parent company and setting a specific tax (different from the default), the default tax was incorrectly added back to the product.
This happened because the logic considered the branch an "other company" and applied its default tax.

**FIX:**
Exclude branch companies from the domain when we set the default tax of other companies on the product.

**Steps to reproduce:**
1. Create a branch company. (It will automatically have the same default tax as its parent).
2. With the parent company selected, create a new product, leaving the 'Company' field empty, and change its sales tax to any tax other than the default, and save.
3. Notice that the default tax is set again on the product.

opw-5094415

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

Forward-Port-Of: odoo/odoo#229066

When the company fiscal year is not the first of the year (Aug 1 → Jul 31), creating a tax return for the fiscal year (2024-08-01 → 2025-07-31) wrongly triggers the wizard’s “wrong dates” warning. The wizard validates the range by slicing it into periods via `_get_period_boundaries()`, which anchors the first period using `_get_start_date_elements()`. If we dont have `deadline_start_date` that anchor falls back to a fixed Jan 1 (calendar year) instead of the company’s fiscal-year start. Consequently, the first computed period becomes 2024-01-01, so the check sees a mismatch and flags the warning even though the user’s dates are perfectly aligned with the fiscal year. 

The fix is to use the company’s fiscal-year start as the anchor for period slicing instead of silently defaulting to Jan 1.
`_get_start_date_elements()` still prefers the explicit `deadline_start_date` (unchanged behavior for calendar-anchored VAT returns), and otherwise derives the day/month from `company.compute_fiscalyear_dates(today)['date_from']`.

Steps to reproduce:
Accounting: Settings and set Fiscal Year End to July 31 Reporting: tax reports and set it to Year and the year to 2024 Top left there is the Return, click on it and set:
 - Opening Date: 08/01/2025
 - Fiscal Year End: 31 July
 - VAT Periodicity: Annually Creat a new tax return and chose any type and set:
 - start date 08/01/2024
 - end date 07/31/2025

opw-4990676

### Issue: 
The partner ledger does consider lines without partners when calculating the initial balance.

### Steps to reproduce:
- Create an invoice in 2025
- Create an entry in 2025 without partner for the same amount
- Reconcile the two
- Open the partner ledger for 2025, everything is correct
- Change the dates to 2026, the amount of the initial balance ignores the entry but not the totals

### Cause:
The method `_get_sums_without_partner` is called for the totals, but not for the initial balance. Its purpose is to add the amounts of the lines without partners that were reconciled with lines with a partner.

### Solution:
Call `_get_sums_without_partner()` in `_get_initial_balance_values()` add the results before returning the initial balances.

As this is the same logic as `_query_partners()` we create a new method.

This method needs to be called with the dates of the initial balance in the options. So we create a duplicate of the options and input the new dates options.

opw-5068790

Forward-Port-Of: odoo/enterprise#96125
Forward-Port-Of: odoo/enterprise#95881