Steps to reproduce the issue:
=================================

1. Go to Website > Products and edit a product.
2. In the product description, add a header using the editor.
3. You can now drop an image in that place, so drop it.
4. Click on the image and try to add an anchor for it.

-> Traceback

Cause:
======

The reason an image can be dropped in that location is because the editor
added an adjacent element, such as a `<p>` or `<h1>`, which is considered
a valid drop zone by the drop zone plugin. However, when trying to
create a link, the parent element checks if it is valid to have an
anchor, but then when adding an anchor the element text is undefined,
causing a traceback.

Why can an image be dropped in that location after adding the editor?
The bug was due to passing `excludeNearParent` as a property name instead
of `excludeParent` to the `getSelectorSiblings` function, which always
evaluated to false. So it allowed dropping images in invalid locations.

Solution:
=========
Pass the correct property name.

Impact:
=======
This fix enforces the intended dropzone behavior where content snippets
(like images, buttons with `.o_snippet_drop_in_only`) cannot create
dropzones next to elements that are direct children of `.oe_structure`
containers.

Test Changes Required:
=======================
The button tests were failing after the fix because they were testing
buttons as direct children of
`<div id="wrap" class="oe_structure oe_empty">`. This was only working
before due to the bug - `excludeNearParent` was being ignored.

The fix wraps the test buttons in a `<div>` container,
making them children of a child of `.oe_structure` rather than
direct children.

opw-5489444

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

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

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

Currently, a task remains linked to its original sales order even when it has no sales order item. This prevents users to not bill a task and temporarily detach it from a sales order until it can be linked to a new one.

**Steps to produce:**
* Install Sales, Project
* Products > Virtual Home Staging > Create On Order > Project and Task
* Create and confirm quotation with that product.
* Tasks > Empty the Sale Order Item Field

**Observed Behavior:**
* Sale Order is still linked to the task despite sale order line has been unlinked from that task.

**Root cause:**
* Compute method [1] only detaches the sale order if the customer has been changed.

**Solution:**
* Only detach the sale order when there are no sale order items and the record
  is not a field service task.
* Field service tasks should always keep the sale order linked so materials can
  still be added to the existing sale order, even when the task is non-billable
  (i.e., no sale order line is linked). This logic is handled by the compute
  override at [2], which reassigns the sale order when needed.

[1]:
https://github.com/odoo/odoo/blob/3f4e45ecaca46a98c904536658728a1f1571bdbd/addons/sale_project/models/project.py#L916-L935
[2]:
https://github.com/odoo/enterprise/blob/6658581828dcdc43ffc5823814a05cb936cd0500/industry_fsm_sale/models/project_task.py#L178-L194

Related Enterprise PR: https://github.com/odoo/enterprise/pull/103487

opw-5215989

Forward-Port-Of: odoo/odoo#249107
Forward-Port-Of: odoo/odoo#241446

Steps to reproduce:
- Have facturae modules installed
- Generate invoice with any amount
- Send to Facturae

Issue:
Resulting XML has 8 digits after the decimal point on several fields, such as unit price, gross amount, and total cost.

When trying to validate such an XML, this results in validation error: "RCF06001: En facturas emitidas en euros, alguno de los importes de las líneas tiene más de dos decimales (regla 6a del anexo II de la Orden HAP/1650/2015)."

According to regulation HAP/1650/2015 [1]: For invoices issued in euros, it will be validated that the total line amounts related to the total cost are numeric and rounded, according to the common rounding method, to two decimal places.
This commit introduces dynamic decimal precision: 2 places for EUR and 8 places (the previous default) for other currencies.

[1] https://www.boe.es/diario_boe/txt.php?id=BOE-A-2015-8844
Machine translated [BOE-A-2015-8844 (1).pdf](https://github.com/user-attachments/files/25345382/BOE-A-2015-8844.1.pdf)


opw-5927356

Forward-Port-Of: odoo/odoo#248882

Currently, a task remains linked to its original sales order even when it has no sales order item. This prevents users to not bill a task and temporarily detach it from a sales order until it can be linked to a new one.

**Steps to produce:**
* Install Sales, Project
* Products > Virtual Home Staging > Create On Order > Project and Task
* Create and confirm quotation with that product.
* Tasks > Empty Sale Order Item Field

**Observed Behavior:**
* Sale Order is still linked to the task despite sale order line has been unlinked from that task.

**Root cause:**
* Compute method [1] only detaches the sale order if the customer has been changed.

**Solution:**
* Only detach the sale order when there are no sale order items and the record is not a field service task.
* Field service tasks should always keep the sale order linked so materials can still be added to the existing sale order, even when the task is non-billable (i.e., no sale order line is linked). This logic is handled by the compute override at [2], which reassigns the sale order when needed.

[1]:
https://github.com/odoo/odoo/blob/3f4e45ecaca46a98c904536658728a1f1571bdbd/addons/sale_project/models/project.py#L916-L935 
[2]
https://github.com/odoo/enterprise/blob/6658581828dcdc43ffc5823814a05cb936cd0500/industry_fsm_sale/models/project_task.py#L178-L194

Related community PR: https://github.com/odoo/odoo/pull/241446

opw-5215989

Forward-Port-Of: odoo/enterprise#107716
Forward-Port-Of: odoo/enterprise#103487

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#107720
Forward-Port-Of: odoo/enterprise#105511