Steps to reproduce
-----
- Enable locations & by products
- Create 4 locations
	- View A of type view (parent: Stock)
	- View B of type view (parent: Stock)
	- Storage A of type internal location (parent: View A)
	- Storage B of type internal location (parent: View B)
- Create a "Manufacture to A" route
	- Rule 1: Manufacture, Stock -> Stock
	- Rule 2: Push To, Internal Transfer, Stock -> View A
- Create a "By Products to B" route
	- Rule 1: Push To, Internal Transfer, Stock -> View B
- Create a "Bonus" product with route "By Products to B"
- Create a "Finished" product with route "Manufacture to A"
	- BoM with "Bonus" as by product
- Create a MO for Finished, and produce it
- Open the linked transfers' list view
- Open the "Bonus" transfer

> "Destination Location" states View B

- Open the line's details (hamburger button)

> "Store To" states View A/Storage A

Cause
-----
When retrieving the location in

https://github.com/odoo/odoo/blob/26dbbdaf460a91ef4b33392c27a28951d5de2c57/addons/stock/models/stock_move_line.py#L280-L282

we pass `locations` as a context key. The problem is that `locations` contains the childs of **all** of the SMLs' locations

https://github.com/odoo/odoo/blob/26dbbdaf460a91ef4b33392c27a28951d5de2c57/addons/stock/models/stock_move_line.py#L260

This means that, in `_get_putaway_strategy`, when no `putaway_location` is found, we end up defaulting to the first element of the list

https://github.com/odoo/odoo/blob/26dbbdaf460a91ef4b33392c27a28951d5de2c57/addons/stock/models/stock_location.py#L370-L371

which might not be a child of the location.

Solution
-----
By removing the context key, locations get populated as such

https://github.com/odoo/odoo/blob/26dbbdaf460a91ef4b33392c27a28951d5de2c57/addons/stock/models/stock_location.py#L328-L330

This is ok because we know the call to `_get_putaway_strategy` is made on a single record (`sml.move_id.location_dest_id`) so the default will correctly be a child of said location.

-----
Ticket:
opw-5359945

## Versions
18.0+
Not visible in 19.0 because the UI prevents this behavior but it still occurs in the backend.

## Issue
In eCommerce, when a customer places an order for in-store pickup at one location, then places another order for pickup at a different store, a problematic address record can be created iff they select the previously used store address (created during the first order) as the delivery address.

This leads to a third address being created with a name combining both store locations, due to improper address parent-child relationships.

## Steps to reproduce
With Admin user:
- In Inventory's "Warehouses", duplicate the existing warehous:
  - Change the duplicated one's address (create one if needed).
- Activate "Click & Collect" in Settings app;
- Setup "Pickup Locations":
  - Under "Pick up in store", add both warehouses.
- Go to a storable and published product (eg. Acoustic Bloc Screens):
  - Set On Hand quantity to at least 2 units per warehouse.

With Portal user logged in:
- Access the shop:
  - Order 1 unit of the setup product;
  - Process checkout up to Delivery step:
    - Select user's address (only available "DELIVERY ADDRESS");
    - Select a store location;
    - Confirm and finalize the order.
  - Order 1 unit of the setup product (bis);
  - Process checkout up to Delivery step (bis):
    - Select the store address (newly created "DELIVERY ADDRESS");
    - Select the other store location;
    - Confirm and finalize the order.
  - Order 1 unit of the setup product (ter);
  - Process checkout up to Delivery step (ter):
    - A third address shows up named after both store locations.

## Cause
The `_action_confirm` method looks for an existing partner based on `parent_id`: https://github.com/odoo/odoo/blob/d80628a45bcfe5192f1b95286a6758fe6616fbec/addons/delivery/models/sale_order.py#L169-L176

The issue comes from:
https://github.com/odoo/odoo/blob/d80628a45bcfe5192f1b95286a6758fe6616fbec/addons/delivery/models/sale_order.py#L164 https://github.com/odoo/odoo/blob/d80628a45bcfe5192f1b95286a6758fe6616fbec/addons/delivery/models/sale_order.py#L178-L189

On the first order:
- A new delivery address is created.
- Its `parent_id` is set to the customer (order partner).

On the second order:
- The user selects the previously created store address as delivery address.
- Odoo sets the `parent_id` of the new address to this store address (instead of the customer).
- This creates an unintended hierarchy, causing further confusion in subsequent orders.

opw-5340953

**Issue 1:**

Steps to Reproduce

- Click on the More options button in the power buttons.
- The powerbox opens, but the editor loses focus and the button receives focus.

Description of the issue:

- After clicking the power button, the button becomes focused and the editor loses focus.

Solution

- When clicking the power button, after the command is executed in the click event, explicitly restore focus to the editable area so the editor remains focused.

**Issue 2:**

Steps to reproduce

- Click More options in the Power Buttons to open the powerbox.
- Start typing `heading`.

Description of the issue:

- The powerbox does not filter commands and continues to show all commands.

Cause:
- In `search_powerbox_plugin`, commands are filtered only when `shouldUpdate` is true.
- `shouldUpdate` is set only when the powerbox is opened through `search_powerbox_plugin`.
- Power Buttons open the powerbox via `powerbox_plugin`, so `shouldUpdate` remains false and filtering is not triggered.

Solution:
- Introduced `openSearchPowerbox` in `searchPowerboxPlugin`.
- Updated the implementation to use this method instead of `openPowerbox` in `search_powerbox_plugin`.
- Instead of opening the powerbox via `powerbox_plugin`, it is now opened via `search_powerbox_plugin`, ensuring `shouldUpdate` is set correctly and commands are filtered on keypress.

task-5485088

Versions:
---
- 17.0+

Issue:
---
Delivery amount is doubled in stripe express payment checkout.

Steps to reproduce:
---
1- Setup a stripe payment express checkout. (In my client case it is apple pay express checkout but we also reproduced it in google pay)
2- Set fixed price on standard delivery: 10
3- Navigate to website: add a product to cart. Use express checkout.

Outcome: The delivery price is calculated twice which is wrong.

Cause:
---
This regression is due to #238574. Once `/compute_taxes` is called, there is delivery lines included in SO. As a result returning `amount_total` will cause `this.paymentContext['minorAmount']` to include delivery amount.
Then we add delivery carrier `minorAmount`:
https://github.com/odoo/odoo/blob/469220cde82ecebf4a59451cc1325add6bfc3e69/addons/payment_stripe/static/src/js/express_checkout_form.js#L188-L196 Which cause delivery amount be added twice.

Fix:
---
We could exclude delivery amount from total amount in `express_checkout_shipping_address_compute_taxes`, which is going to calculate the tax for lines excluding delivery lines.

opw-5424398

Forward-Port-Of: odoo/odoo#248415

**Steps to Reproduce:**
1 - create an employee in Belgium company with hourly rate 20.62 and 40h/week working schedule 2 - Set 10 paid time off to this employee
3 - Set 2000 euros in recovery amount holiday n-1
4 - Set 10 days in recovery day holiday n-1
5 - Employee takes 5 paid time off in February and 5 in December 6 - Do one payslip for this employee for February  and validate it 7 - Do one payslip for this employee for December

Current behaviour :
- the holiday n-1 amount for February = 824.80
- the holiday n-1 amount for December = 742.32

Expected behaviour :
- the holiday n-1 amount for December should be 20.62 (hourly_rate) * 5 (days) * 8 (hours) = 824.80

**Reason**
- The daily recovery amount was calculated using hardcoded standard working hours (38h/week) instead of the employee's actual schedule (40h/week), causing an incorrect deduction rate for non-standard schedules.

**Solution**
- Replace the hardcoded reference with the actual hours per week from the employee's resource calendar to ensure the correct hourly rate is applied.

Forward-Port-Of: odoo/enterprise#106205