Versions
--------
- saas-19.3+

Steps
-----
1. Go to the product page in editor mode.
2. Press the "Add More" button next to "Extra Media"
3. Add an image by URL.
4. Select the new image and press "Add".

Issue
-----
Traceback
```python
Traceback (most recent call last):
  File "/data/build/odoo/odoo/http/router.py", line 432, in serve_db
    return retrying(serve_func, env=request.env)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  ...
  File "/data/build/odoo/addons/website_sale/controllers/main.py", line 757, in add_product_media
    product_product.write({"product_variant_image_ids": media_create_data})
  ...
  File "/data/build/odoo/odoo/orm/fields_binary.py", line 84, in convert_to_cache
    raise TypeError(f'{self}: use BinaryValue instead of {value.__class__.__name__}')
TypeError: product.image.image_1920: use BinaryValue instead of bytes
```

Cause
-----
When saving the image, the remote URL is fetched and the raw `bytes` are stored in the `product.image.image_1920` field. However, since commit 41fe2ebdb9cc37341362d7af829c087a5f72f9f1, raw `bytes` cannot be directly assigned to `Binary` fields.

Solution
--------
Use the new `BinaryBytes` wrapper.

See also:
- https://github.com/odoo/enterprise/pull/116273

Steps to reproduce:
1.Open the website in Edit mode.
2.Add a snippet with an image.
3.Replace the image.
4.After replacing image, double-click on it to open the Media Dialog.
5.Inside the Media Dialog, double-click on the same or any other image.
6.Traceback occurs.

Before this commit:
parentElement was becoming null because parentElement is a DOM
position check.it requires the element to be physically attached in
the DOM tree to find its parent.Since this.props.node is not yet in
the DOM at that point, parentElement returns null.

After this commit:
1.The issue is fixed using a boolean flag: isProcessingClick. Initially,
the flag is set to false. When the first click starts, it is updated to
true. If another click occurs during the same flow
(e.g during a double click), isProcessingClick is already true, so the
function immediately returns and prevents the action from being executed
multiple times.
2.we now pass closestSnippetEl directly from replaceMedia() through
params.this allows the dialog taken snippet reference using
(closestElement(mediaEl , "[data-snippet]")) without depending on the
media node being attached to the DOM.

task-6033320

Forward-Port-Of: odoo/odoo#266664
Forward-Port-Of: odoo/odoo#254790

**Problem:**
Opening a new `mail.link.preview` record from the technical view shows the internal record reference (e.g. `mail.link.preview,NewId_0x...`) in the breadcrumb instead of the standard "New" label.

**Steps to reproduce:**
1. Settings / Technical / Discuss / Link Previews
2. New
3. Observe the breadcrumb

**Current behavior:**
The breadcrumb displays `mail.link.preview,<id>`.

**Expected behavior:**
The breadcrumb should display "New" until the record is saved, and the source URL once saved.

**Cause of the issue:**
The model defines no `name` field and does not set `_rec_name`, so the default `_compute_display_name` falls into its fallback branch and returns `f"{record._name},{record.id}"` — exposing the technical reference in the breadcrumb both for unsaved records (`NewId_...`) and saved ones.

**Fix:**
Setting `_rec_name = 'source_url'` lets the standard display name machinery compute a meaningful label from the existing required field. Unsaved records then surface the standard "New" placeholder via the web client and saved records surface their URL, without introducing a redundant `name` field or overriding the compute.

opw-6095012

Forward-Port-Of: odoo/odoo#263577

Problem: When both line discounts and global discounts are applied on a product in an invoice, the method `_add_and_round_raw_gross_total_excluded_and_discount` does not return the exact raw_gross_total_excluded before the modification done by other AccountTax helper methods, such as dispatching and squashing global discount lines.

Current Behavior: The calculation is done in the wrong order of operations. For example, there is an invoice for Product A valued at $100 with a discount of 10% and a global discount of $10. The raw_total_excluded will be $80 after the both discounts. The discount_factor is based on only the line discount of 10%. The formula of the current calculation for raw_gross_total_excluded is: (raw_total_excluded / (1 - (line_discount / 100))) - global_discount = (80 / 0.90) - (-10)
= 98.889
This does not equal the expected outcome of $100.

Expected Behavior: Based on the previous example, the formula for the calculation should be:
(raw_total_excluded - global_discount) / (1 - (line_discount/100)) = (80 - (-10)) / 0.9
= 100
The global discount needs to be added back to the raw_total_excluded to get the line discounted amount in order to divide by the discount_factor to gain the expected raw_gross_total_excluded before taxes and discounts.

Steps to reproduce the issue:
- Bug was encountered when implementing a global discount solution for l10n_co_dian.
- Create an invoice with a product line and in-line discount and another line for global discount
- Setup the base lines for the invoice and attempt the following:
 - _dispatch_global_discount_lines
 - _squash_global_discount_lines
 - _add_and_round_raw_gross_total_excluded_and_discount

opw-5412446


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

Forward-Port-Of: odoo/odoo#262137

__

## Short functional explanation of the error
When confirming a Purchase Order holding lines with an analytic distribution that has been manually added, and creating a vendor bill out of this PO using the Auto-Complete field. When we change the account of that line, the line loses the manually added Analytic Distribution.

## Reproduction Steps
1. Go to Accounting. Click on the tab Configuration; under the Analytic Accounting section, click on Analytic Distribution Models.
2. Create an Analytic Distribution Model for a product.
3. Go to Purchase. Create a new PO, set a Vendor and select the product you created the Analytic Distribution Model for. On the right side of the form, click on the view menu and check Analytic Distribution to make it appear.
4. Click on the Analytic Distribution of the product and add a new one; for example, select Administrative in the Departments section.
5. Confirm order.
6. Go to Accounting and click on the Vendors tab > Bills. Create a new bill, and in the field Auto-Complete, select the PO you just created.
7. Change the account of the line.

### Expected behavior
Only the account should be changed on the line.

### Unexpected behavior
The manually added Analytic Distribution has disappeared.

## Origin of the issue
When we change the `account_id` field, the compute method `_compute_analytic_distribution` is triggered. This method retrieves the related distributions of the line:
https://github.com/odoo/odoo/blob/af32885ec5f07d492f3b8e8fff1785996a739f72/addons/account/models/account_move_line.py#L1154 which, in the context of Purchase, calls this method: https://github.com/odoo/odoo/blob/af32885ec5f07d492f3b8e8fff1785996a739f72/addons/purchase/models/account_invoice.py#L540-L545 We retrieve the distribution of the related line using `self.purchase_line_id.analytic_distribution`. However, this code isn't triggered when the move line has an analytic distribution, even though the related line `purchase_line_id` might have one! Therefore, we need to execute that code whether or not our move line has an analytic distribution.
Note: the same behavior is to avoid when creating invoices for
quotations.
__
opw-6062466

**Steps to reproduce**
1. Create a customer invoice with Invoice Date `2025-05-27` and accounting Date `2026-05-04`.
2. On the *Other Info* tab, set the Delivery Date to `2026-05-04` and post the invoice.
3. Generate the FA(3) XML.

**Issue**
`P_6` is omitted from the payload even though the delivery date differs from the invoice issue date.

The FA(3) information sheet (Warsaw, September 2025, binding from 1 February 2026) defines `P_6` as *"the date of delivery [...] if such date is specified and differs from the date of issue of the invoice"*, where the date of issue is `P_1` (Art. 106e sec. 1 item 1 of the VAT Act). In Odoo `P_1` maps to `invoice_date`, but the template at
https://github.com/odoo/odoo/blob/4890b8021af2a5c025944220043d295bb7bbbb9b/addons/l10n_pl_edi/data/fa3_template.xml#L132 compares `delivery_date` against `invoice.date`, the accounting/entry date. When the invoice is posted on the delivery day the accounting date equals the delivery date, the guard evaluates to false, and `P_6` is wrongly dropped.

Comparing against `invoice.invoice_date` aligns the guard with `P_1` as the spec requires.

Ticket [link](https://www.odoo.com/odoo/project.task/6211119)
opw-6211119

### Issue before this commit:
Importing a simplified Italian electronic invoice or credit note (e.g., TD08) fails with a float division by 0 traceback if a document line consists entirely of taxes (where the total line amount equals the tax amount).

### Steps to reproduce the issue:
1. Download Accounting and l10n_it
2. Switch to IT company
3. Go to Vendors > Refunds
4. Try to import the xml from the ticket

### Cause of the issue:
The XML parser attempts to dynamically calculate the tax percentage using the formula tax_amount / (amount - tax_amount). When a line is purely a tax adjustment, the taxable base (amount - tax_amount) evaluates to exactly zero, triggering the critical division by zero crash.
https://github.com/odoo/odoo/blob/e3b0ca11d99b2ef819cdad68b169112cd73668b6/addons/l10n_it_edi/models/account_move.py#L1863-L1867

### Reason to introduce the fix:
To ensure Odoo successfully imports valid, tax-only EDI documents already accepted by the Agenzia delle Entrate.

Ticket [link](https://www.odoo.com/odoo/project.task/6217373)
opw-6217373

Forward-Port-Of: odoo/odoo#266374

The _get_putaway_location() method tries to determine a location in which a product can be stored:

https://github.com/odoo/odoo/blob/441a6d1b928a44b9a760f926180a925159edff3e/addons/stock/models/product_strategy.py#L175-L181

When no location can be used, the loop iterates over the whole list
to call _get_weight() method on each one.

We propose to batch the call to _get_weight() method for all locations
that will be used and store the result in a dictionnary passed in the context
to avoid computing them several times during the same delivery preparation.

Benchmarks
--------------

For one product with no possible location:

| No locations | Before PR | After PR |
|------------|--------|-------|
|       780  |    9 s  |   < 1 s |

For 98 products that can be placed in various locations:

| No locations | Before PR | After PR |
|------------|--------|-------|
|       6000  |    20 s |    8 s |

For one product that could be placed in any of the indicated locations, we will compute the weights for every location while only the first one would have been computed without the fix:

| No locations | Before PR | After PR |
|--------------|-----------|----------|
|          500 |     41 ms |   524 ms |
|         2000 |     97 ms |   2.02 s |
|        10000 |    513 ms |  10.83 s |

opw-5949370

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

### Issue
In the Italian annual tax report, both VL3/VL4 and VL32/VL33 values could be displayed at the same time

However, according to the report logic, only the positive balance should be shown for each pair:
- VL3 (Tax Due) or VL4 (Tax Credit)
- VL32 (Tax Due) or VL33 (Tax Credit)

The other one should stay 0
If the global balance is null, both can be 0

### Cause
The lines VL3, VL4, VL32, and VL33 were using the shortcut field `aggregation_formula` directly on the `account.report.line` record
This shortcut format does not evaluate or support conditional subformulas like `if_above(EUR(0))`
As a result, the report computed and displayed both lines of each pair without filtering out the negative or unwanted values

### Steps to reproduce
- Install `l10n_it` and `accountant` and switch to IT Company
- Create a balanced Journal Entry for any account
- Add the Tax Grid v20 on one of the lines to impact the annual report
- Open the `Annual Tax Report (IT)` 
- Go to the `VL` section
- Check the value of VL3/VL4 and VL32/VL33
After the fix, only one value can be positive and the other 0

Ticket [link](https://www.odoo.com/odoo/project.task/6212694)
opw-6212694

### Issue before this commit:
Importing a simplified Italian electronic invoice or credit note (e.g., TD08) fails with a float division by 0 traceback if a document line consists entirely of taxes (where the total line amount equals the tax amount).

### Steps to reproduce the issue:
1. Download Accounting and l10n_it
2. Switch to IT company
3. Go to Vendors > Refunds
4. Try to import the xml from the ticket

### Cause of the issue:
The XML parser attempts to dynamically calculate the tax percentage using the formula tax_amount / (amount - tax_amount). When a line is purely a tax adjustment, the taxable base (amount - tax_amount) evaluates to exactly zero, triggering the critical division by zero crash.
https://github.com/odoo/odoo/blob/e3b0ca11d99b2ef819cdad68b169112cd73668b6/addons/l10n_it_edi/models/account_move.py#L1863-L1867

### Reason to introduce the fix:
To ensure Odoo successfully imports valid, tax-only EDI documents already accepted by the Agenzia delle Entrate.

Ticket [link](https://www.odoo.com/odoo/project.task/6217373)
opw-6217373

Before this commit, a Stripe terminal payment could still be marked as `done` even if the capture step failed.

This happens when the card authorization succeeds, `processPayment` returns a payment intent, but the subsequent `stripe_capture_payment` RPC fails and `capturePaymentStripe()` returns `false`. The capture flow did not guard that return value and still fell through to `line.set_payment_status("done")`.

In practice, this can happen for example if the Odoo server cannot resolve `api.stripe.com` while capturing the payment intent. Stripe then keeps the payment in `requires_capture`, while the POS line is still synced as paid.

Guard the failed capture path and stop the flow before marking the line as done. In that case, the payment line is put back to `retry` so the failure is visible in the POS instead of silently creating a paid, uncaptured payment.

opw-6075384

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

Backport of: https://github.com/odoo/odoo/pull/261521