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

Forward-Port-Of: odoo/odoo#249262
Forward-Port-Of: odoo/odoo#247403

### Issue:

The action used in the ` timesheet approval reminder` email template refair to a non existing action.

### Cause of the issue:

The issue has been introduced in [1](b56e355c400c874f7cd9c3174e2253ad5769a461) b56e355c400c874f7cd9c3174e2253ad5769a461

Starting from 17.3 the actions `action_timesheet_previous_week` and `action_timesheet_previous_month` have been removed and merged in a single action `timesheet_grid_to_validate_action`. See [2](7040535ffe2c08d0d286cfccbaf4cc7f81f18443) 7040535ffe2c08d0d286cfccbaf4cc7f81f18443 However, while [2](7040535ffe2c08d0d286cfccbaf4cc7f81f18443) correctly replaced the usage of both actions used in the template as `action_xml_id`:
https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L209-L221 https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/data/mail_template_data.xml#L43-L45

The forward port of [1](b56e355c400c874f7cd9c3174e2253ad5769a461) replaced it with the deleted action:
https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L161-L171 https://github.com/odoo/enterprise/blob/913418bb3d7558b6b44916455e28de855eb123f5/timesheet_grid/models/res_company.py#L193-L198

opw-5890269

Forward-Port-Of: odoo/enterprise#107385

Fix 1:
-------
Using the early receipt printing option leads to a traceback when using the italian fiscal printer.

Steps to reproduce:
-------------------
* Setup the italian fiscal printer for a restaurant
* Enable Early Receipt printing
* Open restaurant
* Open a table, add an item to cart
* Try the early print option
> Observation: Traceback

Why the fix:
------------
Initially the traceback is related to trying to read `decimal_places` out of undefined. The current order doesn't have yet a currency.

To solve this initial issue we can just take the currency of the config if there's none on the order. The pos does not handle multicurrency so the order will always have the same currency as the config anyway.

After solving this part another issue would still happen. If the order was no sent to the kitchen yet. Such orders are not yet synced to the backend and do not have an id of type number. If the order had been send to the display.

This scenario was sending the printer, the data to print and with a successful print we were trying to sync data to the server with
```
await this.data.write("pos.order", [order.id], updateData);
```
which was triggering an error in `orm_services` with `validatePrimitiveList`.
> Invalid ids list: pos.order_4

If we try to reprint AGAIN the bill for some reason, we get another traceback. It's because the nb_print is now 1 and therefore we now try to print with
```
printResult = await this.fiscalPrinter.printContentByNumbers({
    order: order,
});
```
which will try to split undefined here
```
this.receiptNumber = this.props.order.it_fiscal_receipt_number;
const dateParts = this.props.order.it_fiscal_receipt_date.split("/");
```

Those two last issues are solved by not syncing the data to the server when we simply print the bill early.

-------
-------
Fix 2:
-------
Currently the early printing option does not work as desired. The fiscal printer does not print the receipt.

Steps to reproduce:
-------------------
* Setup the italian fiscal printer for a restaurant
* Enable Early Receipt printing
* Open restaurant
* Open a table, add an item to cart
* Try the early print option
> Observation: the printer stops in the middle of printing the receipt

Why the fix:
------------
The early receipt was trying to be printed as a fiscal document. However it cannot be considered as such.

We backport this fix that enables basic receipt printing and alter it to also work with early printing.

Fix being backported: https://github.com/odoo/enterprise/commit/b8fd13b802729ccee080ab14f2958d59f57d0f97

There are a few differences between the early receipt and the basic print, mainly the fact that prices need to be shown on the early receipt.

There are a few differences with the original commit. In the documentation of the printer, `printNormal` uses data and the original commit mixes between `data` and `message` so it is harmonized here.

opw-5387572


Results:
-----------
Basic receipt:
<img width="672" height="835" alt="image" src="https://github.com/user-attachments/assets/3de96523-22db-4a27-adbd-3464802604aa" />

Early receipt:
<img width="658" height="842" alt="image" src="https://github.com/user-attachments/assets/f6b7ab24-e27b-4deb-8d5f-1b0c41bb28f0" />

Forward-Port-Of: odoo/enterprise#106672
Forward-Port-Of: odoo/enterprise#105511

Steps to reproduce
=================
1. Go to “View all activities”.
2. Switch to calendar view.
3. Click on an activity not linked to any model
(e.g. “Eat cookies”, “Send Email to Alfred”).
4. Click “View” in the popover.
=> Traceback

Reason
======
The commit [1] allow activities without a linked model and from commit [2]
such activities can be opened in the activity form view.

In the calendar view, the action is retrieved from the model and executed
using `doAction`. Since the action does not define `views`, and the `doAction`
depends on `action['views']`, an error occurs when the action service attempts
to copy it.

After this commit
==================
This commit fixes the issue by modifying the action returned from `action_open_document`
for non-linked models to include `views`, similar structure used when a model is present.

[1] https://github.com/odoo/odoo/commit/165b060473be8a5d33d62d311f0dc55ed6332d69
[2] https://github.com/odoo/odoo/commit/abeac135b9bb7aec4bcddd84fb0705743297f80d

Task-5857887

Description of the issue this PR addresses:

I. The power buttons positioning logic was interleaving DOM writes and layout reads during selectionchange, causing repeated style/layout recalculations. This PR reorders the logic so geometry is read first and DOM mutations are
applied afterwards, reducing the number of forced reflows and significantly improving performance.

II. Debounce `updateHints` and `updatePowerButtons` to avoid excessive UI updates on frequent selection changes. Introduce `debounceHints` and `debouncePowerButtons` editor config options so debouncing can be disabled in tests for deterministic behavior.

III. Introduce READ helper for withSequence to explicitly order resource handlers so DOM reads run before DOM mutations.

Before:
<img width="1705" height="399" alt="image" src="https://github.com/user-attachments/assets/2fca797a-0311-4c4a-9063-2051934baa7c" />

After:
<img width="1490" height="343" alt="image" src="https://github.com/user-attachments/assets/0f295969-b962-4190-a7f9-fe5366d7fafd" />


task-5499625

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

In [1], a refactoring of the POS framework was done, but in the process some overlooked behaviors induced a complete loss of the answers given in the registration process, as long as they do not include an answer to a 'selection' question.

STEPS
=====

0. Create a new event with a few questions (no 'selection' one)
1. Add tickets so that you can buy one in the POS
2. Go in the POS (reload data if needed)
3. Buy a ticket and fill the attendee form (answer to all questions)
4. Continue the POS flow and pay for your ticket.
5. Go back to the back-end and event > attendees
6. Check your new attendee: no answers are linked to the record.

ISSUE
=====

TLDR - Two fields have the same comodel on event.registration. This breaks the use of inverseMap as both are loaded in the pos. As they are treated sequentially when connecting related records, hidden side effects occur when both are not set.

Details:

This effect is due to two main issues. First, after [1], we compute the whole model reference relations using processModelDefs method, that accounts for inverse relations of o2m, m2o fields and provides an inverseMap to be used in several places, notably on creation or deletion of relational records from the POS.

However, pos_event presents a peculiar situation, as registrations have two o2m fields, both loaded in _load_pos_data_fields, that are linked to the model event.registration.answer: registration_answer_ids and registration_answer_choice_ids, a subset of the first, just with a domain to only include answers of 'selection' questions.

Meaning that the inverseMap will only use one of the two, in this case registration_answer_choice_ids. In turn, this means that any update of registration_id on the answer model will update that field, even if the original update was done on registration_answer_ids...

Secondly, one could notice that this should still work, as the inverseMap is used in all places, we should just update the records through the field registration_answer_choice_ids.

So why does it not work and why are all answers removed? Because both fields are loaded in _load_pos_data_fields, and in _sanitazeRawData we use getFields to know which fields to update and to connect (for relations on the model), both being returned.

This means that independantly of the create values for the registration in addProductToOrder in pos_event, the 'framework' will still have two fields to connect and will do so sequentially, one field at the time.

But in the _connect logic, if a field has no value given at creation, then the 'CLEAR' command is used, as this would mean we remove the content of the relational field. But in this case, this means that as both answer fields try to update registration_id through registration_answer_choice_ids, if no value is given at creation in that field, then we clear existing ones, for instance those we just linked through the creation values in the first field registration_answer_ids, as we basically empty registration_id on those records. The answers will also be deleted of the indexedDB because of the condition in databaseTable (no linked registration -> can be removed)

FIX
===

Remove registration_answer_choice_ids from the loaded data, as it is not used anywhere except in the registration creation values. As it is a subset of the other field registration_answer_ids, only keep that one instead. Update the creation values to only use that field.

Note that this seems to highlight a limitation when it comes to having more than one o2m field on a model loaded at the same time in POS.

[1] odoo/odoo@a80a39f2ad16baf474553574c79d55948f86c453

Task-4919080

Steps to reproduce:
- Install `account` module
- Taxes > open any existing tax > Set `factor_percent(%)` of repartition lines to negative(eg: [Image](https://www.awesomescreenshot.com/image/58851592?key=ce0017bb467a583ad020f33d21d4d8ba))
- Create a Invoice and add tax in move line and save

Traceback:
`IndexError: list index out of range`

We are getting `factors` as empty because `target_factors` from `_add_accounting_data_to_base_line_tax_details` is empty.

This happens because, in `tax_reps`, we are filtering repartition lines with a `factor` greater than `0`. However, when the `factor` is less than `0`, `tax_reps` becomes empty, which leads to the error.

We are reverting this PR: https://github.com/odoo/odoo/pull/234334 because it prevents the validation error from being raised when there is a negative value in the repartition lines.


[factors]: https://github.com/odoo/odoo/blob/de056cc784a3bbe2575fd3c9e81ca62e73c362d4/addons/account/models/account_tax.py#L1641

[tax_reps]: https://github.com/odoo/odoo/blob/de056cc784a3bbe2575fd3c9e81ca62e73c362d4/addons/account/models/account_tax.py#L2429-L2431

sentry-7102210210

Forward-Port-Of: odoo/odoo#249220

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#249340
Forward-Port-Of: odoo/odoo#248415