Steps to reproduce:
- Install the `l10n_es_reports` module and switch to the `ES company`.
- Go to Invoices and create an invoice with taxes, then confirm it.
- Navigate to Accounting > Reporting > Tax Report.
- From the smart button, select `Report: Tax Report (Mod 390) (ES)` and 
  choose the year as `This Financial Year`.
- Download the `BOE` file using the dropdown and fill the wizard fields 
  (e.g., Natural Person – Name: Test, Principal activity: Test, Activity Code: 12345).
- Upload the generated .txt file to the AEAT portal. (AEAT credentials are required)

**Observation:**
AEAT rejects the file with:
`Caracteres no válidos '4. Representante - Personas Jurídicas - Represent. 1 - Fecha Poder (DDMMAAAA)'`

**Root cause:**
At [1], when `judicial_person_procuration_date` is `false`, an empty string is 
written to the BOE file, resulting in blank spaces in the exported file. This 
does not comply with AEAT’s required numeric format and causes the file 
to be rejected.

**Fix:**
This commit ensures the file contains '00000000' when 
`judicial_person_procuration_date` is false, complying 
with AEAT numeric format requirements.

[1]:
https://github.com/odoo/enterprise/blob/45d3a537c3b2eaccee425d959e89d26229e376cd/l10n_es_reports/models/aeat_tax_reports.py#L1696

opw-5995290

Forward-Port-Of: odoo/enterprise#109652

This commit aims to provide better support for contract changes that happen in the middle of a pay period.
It has a few impacting changes, notably:

1) Payslip calculation sequencing
As of now, all payslips of a same payrun have their line calculated all at once. While this is better for performances, it has a negative effect when a single employee has multiple payslips in the same payrun.
In such cases, we may want or need for the payslips to know what was already calculated in the same payrun to avoid overpaying contributions or allowances that have caps.

To solve this issue, we now group payslips by employee, sort them chronologically, and evaluate them in horizontal "layers":
  - Layer 1: Computes the 1st payslip for ALL employees simultaneously.
  - Layer 2: Computes the 2nd payslip for the subset of employees who have one, etc

2) More tools in HK payroll to support these cases The payslip rules now have a `l10n_hk_payrun_totals` dict that contains the total amount already reported in previous payslips of a same payruns for a selection of rules that needs it. We also provides a `worked_days_prorata_rate` which gives the ratio of worked days vs unworked days in a month for cases where we need to adjust amounts based on that ratio.

3) Rule updates
The last part of the fix requires some updates in a few rules that are fixed amounts/not based on the wage and ends up being counted double in our use case. These rules will now take into account already computed amounts as said above to avoid going over the limit.
In most cases it will only affect that specific use case, with a small exception for fixed mpf voluntary contributions, which have been updated to be prorated based on the worked days in the month.

Forward-Port-Of: odoo/enterprise#111814
Forward-Port-Of: odoo/enterprise#111570

In multi-country databases, a Peruvian company can invoice a foreign customer (e.g., a Colombian company) whose identification type is defined by another localization. Those records typically have an empty l10n_pe_vat_code, since there are no cross-country dependencies between LATAM identification types.

In that case, the generated UBL leaves the receiver identity type empty and SUNAT returns an error like:
```
2015/2015 - El XML no contiene el tag o no existe informacion del tipo de documento de identidad del receptor... (missing schemeID value).
```

Odoo already defines schemeID = 0 for some foreign identification types in l10n_pe data, but it cannot cover identification types coming from other countries’ localizations (e.g. Colombia):
https://github.com/odoo/odoo/blob/18.0/addons/l10n_pe/data/l10n_latam_identification_type_data.xml#L4

This change ensures that, when the partner is not from Peru and the PE VAT code is missing, we fallback the receiver identification type to "0" in:
- PartyIdentification/ID/@schemeID
- AccountingCustomerParty/AdditionalAccountID
- the QR payload identification type field

This prevents generating invalid UBL/QR content for foreign customers in multi-country setups.

Forward-Port-Of: odoo/enterprise#110324
Forward-Port-Of: odoo/enterprise#105115

The interaction for filling the dynamic content of dynamic snippets
did not run inside the iframe to preview the snippet to add. This is
not an issue for the initial dynamic snippet, as they are filled with
fake content. But when saving a custom snippet, the dynamic content is
cleared, and they seem empty when previewed. This is the case since the
[website builder refactor] as the previous builder re-used the preview
of the initial snippet.

This commit adds the interaction to fill dynamic content in the preview
iframe, and changes the interaction to avoid emptying the fake content
from initial dynamic snippets during preview.

Steps to reproduce:
- Open website builder
- Add a dynamic snippet (for example "Events")
- Save the snippet as a custom snippet
- Click on "Custom" snippet category
- Bug: The preview for the custom snippet does not have the dynamic part
(there is no event, just the title)

[website builder refactor]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2

task-5427353

Forward-Port-Of: odoo/enterprise#110696
Forward-Port-Of: odoo/enterprise#108912

[FIX] documents_account: sync all XML documents for account moves

Before this commit, the synchronization between accounting attachments and
the Documents app was incomplete regarding XML files (e.g., e-invoices, Peppol).

This caused several specific issues:
1. When creating an invoice via the Accounting upload interface, only the
   generated PDF was synced to the correct Documents folder, leaving the
   original XML file unsynced.
2. When creating an invoice from an existing file in the Documents app
   (via server action), the system correctly synced the generated PDF,
   but failed to move or sync the original XML source file to the
   target folder.
3. When receiving vendor bills via Peppol or other EDI networks, the proxy
   attaches the fetched XML to the `account.move` via an `ir.attachment` 
   write. Because this bypassed the existing sync filters, the Peppol XMLs 
   were never pushed to the Documents app.

This commit updates the `ir.attachment` logic in both `create` and `write`.
It ensures that whenever an XML file (mimetype `application/xml` or `text/xml`)
is attached to an `account.move`—regardless of the move type or whether it 
was uploaded manually or fetched via EDI—the document synchronization logic 
is triggered, properly linking and filing the XML alongside the PDF.

Task-5909245
Task-5917535

Forward-Port-Of: odoo/enterprise#111881
Forward-Port-Of: odoo/enterprise#106574

Currently, when a product has a tag that is configured as an Excluded Tag on the Pick Up in Store delivery method, the method is still shown on the product page.

Steps to produce:
---
- Install `website_sale` module.
- Enable `Click and Collect` in settings.
- Go to `website > ecommerce > products > product tags.`
- Create a new tag and add a product in product template.
- Go to` website > configuration > ecommerce > delivery method.`
- Open` pick up in store`:
    - In the `Stores` tab, set your company warehouse.
    - In the `Availability` tab, add the created tag to Excluded Tags.
    - Publish the delivery method.
- Open the tagged product on the website.

Issue:
---
- The Pick Up in Store option is still displayed on the product page, even though the product has a tag listed in the carrier’s Excluded Tags.

Root cause:
---
- Here at [1], the method `_get_additional_combination_info ()` does not check whether the product has tags that are excluded by the delivery method.
- However, at [2], during checkout, the exclusion works correctly because `_match_excluded_tags` in `delivery.carrier` filters the carrier based on excluded tags.

Solution:
---
- Hide the Pick Up in Store option when the product has tags excluded
  for that delivery method. This keeps the behavior consistent across
  the website, avoids showing unavailable delivery options, does not
  impact other flows and aligns with the existing behavior during
  checkout.

[1]https://github.com/odoo/odoo/blob/1c483c3a8d7d079bd34a378f9f8716551e4bab93/addons/website_sale_collect/models/product_template.py#L17-L21
[2]https://github.com/odoo/odoo/blob/1c483c3a8d7d079bd34a378f9f8716551e4bab93/addons/delivery/models/delivery_carrier.py#L192-L194

opw-5921268

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

Forward-Port-Of: odoo/odoo#255482
Forward-Port-Of: odoo/odoo#250837

Steps to reproduce
===============
Issue 1
---------
1. Open any email template's form view
2. Click the `Preview` button -> Preview wizard will open
3. Remove the record from the record selector
4. Click the next button of the pager. -------> Traceback

Issue 2
---------
1. Open email marketing
2. Open any mailing
3. Click the `Preview & Test` button -> Preview wizard will open
4. Remove the record from the record selector. -------> Record selector and the pager will disappear.

Technical
========
Issue 1
----------
The [line] mistakenly used `display_name` instead of `displayName` to access from the record, making the _first_ record's display_name `undefined`. When we switch to the next record,  the code used the resModel of the current record raising
the error through `update -> _update -> _preprocessReferenceChanges ->
_completeMany2OneValue -> webRead`, the cause being the `undefined` value of resModel passed to the `webRead`.

Notably, this problem would've been omitted if:
-> `display_name` of the first record wasn't `undefined` as it would've prevented the call to `_completeMany2OneValue`
or
-> use the `getRelation` method as `resModel` of the reference field while updating.

After this commit, we make sure to apply the above both points.

Issue 2
----------
The reference field sets the `relation` of the current field from the current value or the provided `model_field`.
When unsetting the record, the current value is set to `false`. Therefore, the `relation` value is `undefined` making the record selector disappear (See [Ref])

After this commit, we add the computed `model_id` field to the wizard's model and provide it to the preview record field.

[line]: https://github.com/odoo/odoo/blob/07378556a633f50938c92b7abe094cf2adf43c2c/addons/mail/static/src/views/web/fields/mail_preview_record_field/mail_preview_record_field.js#L24
[Ref]: https://github.com/odoo/odoo/blob/35785af180c68075a94f3f1464b8dddf526a0646/addons/mail/static/src/views/web/fields/mail_preview_record_field/mail_preview_record_field.xml#L5

Task-5944834

**Steps to Reproduce:**
- Create a new database.
- Install any module (for example, Payroll).
- Go to Settings → Technical → Security → Groups.
- Open any group and assign an inherited view in the Views section.
- Upgrade the module.

**Issue:**
- Odoo already prevents assigning groups directly on inherited view records in
ir.ui.view. However, it is still possible to indirectly assign groups to
inherited views through res.groups via the view_access relation.

- This creates entries in ir_ui_view_group_rel and can trigger a ValidationError
during module upgrades. As a result, users may unknowingly create invalid
group-view relations, leading to errors and confusion.

**Solution:**
- Add a validation constraint on res.groups to prevent linking groups to
  inherited views via the view_access relation.

- Raise a ValidationError when such an assignment is attempted, with the message:
  "Groups should instead be defined using the 'groups' attribute inside the view XML definition."

This ensures that inherited views cannot be assigned to groups,
avoiding invalid configurations and preventing errors during module upgrades.

**opw-6015526**

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

Forward-Port-Of: odoo/odoo#255411
Forward-Port-Of: odoo/odoo#254849

**Step to reproduce:**
- install "l10n_es_edi_verifactu_pos"
- setup "ePOS printer" for a pos
- open pos and settle a order below 400$
- notice we get l10n_es_edi_verifactu_qr_code in our receipt
- click on "Print receipt"
- repeat above steps for one more order

**Observation:**
- when we print the second order receipt, the QR still points to 1 order invoice

**Issue:**
- [getCacheKey](https://github.com/odoo/odoo/blob/0cee3350df09b06af77c879f0eba74bf6a8dd2c9/addons/point_of_sale/static/src/app/utils/html-to-image.js#L351C10-L355
) was trimming query strings when generating cache keys. URLs like:
`  http://localhost:9000/report/barcode/?barcode_type=QR&value=... `
were reduced to:
`  http://localhost:9000/report/barcode/`

- As a result, different QR code requests shared the same cache key. Subsequent requests reused the previously cached image instead of fetching a new one, producing incorrect QR codes for different orders.

**Solution:**
Add an `includeQueryParams` flag to `resourceToDataURL` so the full URL, including query parameters, is used as the cache key when needed. This ensures unique QR code URLs are cached and fetched correctly.

opw-5455807


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

Forward-Port-Of: odoo/odoo#251139

Before this commit:
---------------------------------
Long property names in the worksheet properties dropdown (ModelFieldSelector)
were overflowing and overlapping with the chatter, causing a poor user
experience and making it difficult to select and configure rules.

Steps to reproduce:
-------------------------
1. Install the quality_control_worksheet module.
2. Create a new Control Point.
3. Set the Type to Worksheet and select a Worksheet Template.
4. Open the selected Worksheet Template and add a property with a very long name.
5. Return to the Control Point, create a rule, select Worksheet Properties, and
   choose the property with the long name.
6. Observe that long labels overflow and overlap with the chatter, making
   selection difficult.

After this commit:
--------------------------------
This fix applies CSS to properly handle long text, preventing layout issues and
improving readability and usability, resulting in a smoother and more
user-friendly experience.

Before:

<img width="1916" height="789" alt="image" src="https://github.com/user-attachments/assets/ec585c21-bcce-4fed-a847-db42511f5f69" />

After:

<img width="1329" height="819" alt="image" src="https://github.com/user-attachments/assets/bb39e4bf-93b7-4885-80b2-ef75da8398f6" />

Enterprise PR: [110899](https://github.com/odoo/enterprise/pull/110899)
Task Id: 5955976

# How to reproduce
- Go to the Pysical Invetory list view
- Select more than one record
- In the Counted field, try to type a two digit number

# The problem
A popup asking for confirmation for editing a field is shown before the user has the time to type in the other digits. This makes it so it is not possible to input a number that has more than one digit.

# Cause
The Counted (invetory_quantity) field in the list view uses a special widget (CountedQuantityWidgetField). This widget has the responsability to set the inventory_quantity_set field to true when the the value of the inventory_quantity field is updated.

The inventory_quantity_set field is updated on input :
https://github.com/odoo/odoo/blob/f450bb6379b5c0354c048abcc688428d8bff1172/addons/stock/static/src/widgets/counted_quantity_widget.js#L33-L35

The inventory_quantity field is updated on blur :
https://github.com/odoo/odoo/blob/f450bb6379b5c0354c048abcc688428d8bff1172/addons/stock/static/src/widgets/counted_quantity_widget.js#L44-L49

This does not make a lot of sense, because we tell the backend that the quantity has been changed before sending the new quantity. This was not really an issue before but starting in 19.0, this commit (https://github.com/odoo/odoo/commit/9f0470b48e4e8c783513788e269ad16cbf84b7af) made the Physical Invetory list view multi-editable, highlighting the desynchronization

This fix aims to resynchronize the editing of both of theses values, allowing the bulk edit at the same time.

opw-5908205

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

Forward-Port-Of: odoo/odoo#254399

To compute the inventory valuation report, stock_account builds a valuation context through `_with_valuation_context()` and passes the valued internal/transit locations to stock quantity computation.

Without `strict=True`, stock quantity domains treat these locations as hierarchical anchors and expand them again through the location tree. This is redundant in this specific call site because `_with_valuation_context()` already provides the valued locations to filter on.

On databases with a large location tree, this extra expansion makes the inventory valuation load much slower than necessary.

Using `strict=True` makes quantity computation use the provided valued locations directly.

### Benchmark:
- active products: 5912
- stock moves: ~785k
- internal locations: 4213

| Before  | After  |
|---------|--------|
| 99.285s | 1.853s |

opw-5944584

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

Forward-Port-Of: odoo/odoo#254354
Forward-Port-Of: odoo/odoo#253656

Steps to reproduce:
- Go to Azure Interior contact form:
  - Sales & Purchase tab > Group RFQs > Always
- Create a storable product "P1":
  - Route: Resupply Subcontractor
  - BoM:
    - Type: Subcontracting
    - Component: C1 with Dropship route and azure interior as vendor
- Create a storable product "P2":
  - Route: Resupply Subcontractor
  - BoM:
    - Type: Subcontracting
    - Component: C2 with Dropship route and azure interior as vendor
- Create a purchase order with one unit of P1 and P2
- Confirm the purchase order

Problem:
Two RFQs are generated (one for C1 and one for C2) instead of a single grouped RFQ.

When confirming the purchase order, a stock reference is created and assigned to it. This reference is correctly propagated to the picking and stock moves.

However, when the two manufacturing orders are created, new stock references are generated instead of reusing the original one. As a result, each MO ends up with a different reference:

https://github.com/odoo/odoo/blob/2713876dbc70d3984e584a9037a2206dcda4e84a/addons/mrp_subcontracting/models/stock_picking.py#L69-L72

This prevents from grouping RFQs, since the grouping logic relies on identical references. When the first RFQ is created for C1, it uses the MO reference, and when searching for a candidate RFQ for C2, none is found due to the reference mismatch:
https://github.com/odoo/odoo/commit/77dc92e4a0db0575a1a0e865cdd0c82978d593f6#diff-201f9fd7ec1067f7530aafeaa88420021930be82ce89e912d595ed55bb885f26R370-R372

Solution:
Reuse existing stock references when creating subcontracting MOs instead of creating new ones.

opw-5895378

Forward-Port-Of: odoo/odoo#254327

When a delivery address is selected as the customer in the POS UI and an invoice is generated from the POS order, it results in two different `partner_id` being set on the `pos.order` and the `account.move`. It is expected, as a delivery address cannot logically be used as an invoicing address.

Anglo-saxon accounting registers the COGS with additional account.move.line on the invoice and, when using real time valuation, the balance of these lines is calculated from values found on the corresponding `stock.move`.

Currently, the `stock.move` cannot be found if the `partner_id` on the `pos.order` and the `account.move` are different. The system then falls back on the `standard_price` of the `product_id`, which is incorrect. In version 19+, the `product_id` used to calculate the unit price is fetched from the `stock.move` but, because it's an empty recordset, the balance of the COGS is 0 and the lines are not created.

An easy fix could be to remove this check of equivalence between the two `partner_id`. The invoice is created directly from the POS order anyway. I am not sure why it is necessary. Am I missing something?

Steps to reproduce:
1. Create a product with fifo and automated valuation. Make sure that the product type is storable.
2. Validate one purchase and its delivery for the product (qty 5, unit price 5).
3. Validate another purchase and its delivery for the product (qty 5, unit price 10).
4. Configure the point of sale to allow invoicing.
5. Open a pos session then sell 1 item of the product. Select a delivery adress as the customer and generate an invoice.
6. Since the product is fifo, this means that the cost of goods sold is 1 * 5.
7. The correct expense account line should have balance of 5.0.
8. The correct output account line should have balance of -5.0.
9. The COGS lines instead have a balance of 8.13 and -8.13 which corresponds to the standard price of the product at the time of the invoice.

Related ticket: opw-5467877

Forward-Port-Of: odoo/odoo#245208

**Steps to reproduce:**
- Install Accounting and l10n_be
- Switch to a Belgian company (e.g. BE Company CoA)
- In Accounting settings:
  * activate Peppol
  * set "Rounding Method" to "Round Globally"

- Create an invoice:
  * Customer: [a Belgian customer with a VAT]
  * Invoice Lines:

    | Label | Quantity | Price | Taxes | 
    | ------- | ---------- | ------- | ------- |
    |  Line 1   |   1.0    | 90.30 |   0%  |
    |  Line 2   |   0.45   |  2.54 |   6%  |
    |  Line 3   |   0.28   |  6.87 |   6%  |

- Confirm the invoice
- Send the invoice to Peppol

**Issue:**
The generated XML has a line with `<cbc:LineExtensionAmount>` set to 90.31, `<cbc:InvoicedQuantity>` set to 1.0 and `<cbc:PriceAmount>` set to 90.30, which fails the validation with the following error:

`[BR-E-08]-In a VAT breakdown (BG-23) where the VAT category code (BT-118) is "Exempt from VAT" the VAT category taxable amount (BT-116) shall equal the sum of Invoice line net amounts (BT-131) minus the sum of Document level allowance amounts (BT-92) plus the sum of Document level charge amounts (BT-99) where the VAT category codes (BT-151, BT-95, BT-102) are "Exempt from VAT".`

**Cause:**
The use of decimal number in quantity generates a 0.01 rounding difference in the base amounts.
The extra cent is dispatched in one of the `<cbc:LineExtensionAmount>` node.

**Solution:**
There is no easy solution to handle these rounding cases. The solution used in this fix is to handle the extra cents as if they are cash rounding amount and declare them in `<cbc:PayableRoundingAmount>` node.

opw-5933545




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

Forward-Port-Of: odoo/odoo#255224
Forward-Port-Of: odoo/odoo#253625

Case 1:
---
**Steps to produce:**
- Install `pos_sale` module.
- Enable `Automatic Invoice` in settings
- Create a new SO with product price 1000.
- In `Other Info`, set `Online Payment` to 30%.
- Preview > make payment > down payment of 300 is created in SO.
- In POS, open Furniture Shop register > Actions > Quotation/Order > select the SO > settle order.

**Issue:**
- The down payment line is added twice in the POS order.

**Root cause:**
- At [1], `sale_order.amount_paid` = 300, so `addDownPaymentProductOrderlineToOrder` adds the line in order.
- At [2], the down payment line from the SO is added again.
- Here, when `Automatic invoice` is on and we make the online payment
  then `amount_paid` is updated and the downpayment invoice is also created.
- So, we have also downpayment line in sale order also.

**Solution:**
- Ensure that if a downpayment line has already been added to the POS order,
  the first downpayment line matching `amount_paid` is skipped.

[1]: https://github.com/odoo/odoo/blob/54a62bdbe927108a7f85374db26787f8ba45f6ac/addons/pos_sale/static/src/overrides/models/pos_store.js#L88-L93
[2]: https://github.com/odoo/odoo/blob/54a62bdbe927108a7f85374db26787f8ba45f6ac/addons/pos_sale/static/src/overrides/models/pos_store.js#L109-L111

Before:
<img width="484" height="279" alt="image" src="https://github.com/user-attachments/assets/c803c9bd-0751-4a90-81f4-8fb3da3b393e" />


After:
<img width="490" height="235" alt="image" src="https://github.com/user-attachments/assets/2ec4ac43-1db3-4c2e-bfcf-8c52a4830dac" />

Case 2:
---
**Steps to produce:**
- Install `pos_sale` module.
- Enable `Automatic Invoice` in settings
- Create a new SO with product price 1000.
- In `Other Info`, set `Online Payment` to 30%.
- Preview > make payment.

**Issue:**
-The computed value of amount_unpaid is 400, whereas it should be 700.

**Root cause:**
- When Automatic Invoice is enabled and an online payment is made, the invoice
  is automatically created and amount_paid is also updated.
- At [3], the logic subtracts both the total invoice amount and amount_paid from
  the actual total, which results in an incorrect calculation.

**Solution:**
- When an online payment is made, a transaction is created and linked to
  an invoice.
- While computing the total invoice amount, if the transaction’s invoice ID is
  encountered again, it should be skipped to avoid double-counting.

[3]: https://github.com/odoo/odoo/blob/75f6be6744006ed1a3c0857881822723f90f5d4a/addons/pos_sale/models/sale_order.py#L46-L51

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

Forward-Port-Of: odoo/odoo#255474
Forward-Port-Of: odoo/odoo#242026

Steps to reproduce:
1. Go to an Email Template (e.g., 'Invoice: Send by email') and set a specific 'Reply-To' address.
2. Open a posted Invoice and click the 'Send & Print' button.
3. Ensure the 'Email' method is selected and click 'Send'.
4. Observe the sent email in the chatter or the mail queue. Observation: The 'Reply-To' header is overwritten by the system's catchall or author email, ignoring the template setting.

Cause:
The 'account.move.send' logic processes email data via the '_get_mail_params' method. This method manually constructs a dictionary of parameters to be passed to 'message_post'. However, it only explicitly includes a fixed set of fields (author_id, body, subject, partner_ids, and attachments), effectively filtering out the 'reply_to' value. When 'message_post' is called without this key, Odoo's mail thread logic defaults to the standard '_notify_get_reply_to' calculation, causing the custom template configuration to be lost.

Solution:
Update the '_get_mail_params' method to safely extract the 'reply_to' value from the move data and include it in the parameters dictionary passed to the mail engine.

opw-5922963

Forward-Port-Of: odoo/odoo#255489
Forward-Port-Of: odoo/odoo#249116

### Steps to reproduce:

- Ensure that sale_stock is installed
- In the settings enable Multi-Steps Routes
- Inventory > Configuration > Warehouse Management > Warehouses
- Create a second warehouse WH2 and enable: Resupply from WH1
- Create a physical product using the route: Resupply from WH1
- Click on the product form cog wheel icon > Replenish
- Replenish 1 unit to warehouses 2
#### > The delivery that was created from WH1 to the inter company transit location does not set the `partner_id` (delivery address) to the partner of warehouse 2.

### Cause of the issue:

Triggering the replenish will create a move chain relying on the `_run_pull` mechanich. In particular,
the receipt move will be created first from Inter-company transit to `WH2/Stock` without `partner_id`:
https://github.com/odoo/odoo/blob/b9845f693af28e1d9fac773ae391b29f6831e982/addons/stock/models/stock_move.py#L1709 https://github.com/odoo/odoo/blob/b9845f693af28e1d9fac773ae391b29f6831e982/addons/stock/models/stock_move.py#L1674-L1677 Then, during its confirmation, the delivery move from WH1/Stock to the intercompany transit location will be created based on the rule and, thanks to these lines:
https://github.com/odoo/odoo/blob/b9845f693af28e1d9fac773ae391b29f6831e982/addons/stock/models/stock_rule.py#L342-L349
The `partner_id` of WH2 will be set as the `partner_id` of the delivery. Since there is a single partner this will also set the partner of the `move_values` of the delivery move we are creating to this partner:
https://github.com/odoo/odoo/blob/b9845f693af28e1d9fac773ae391b29f6831e982/addons/stock/models/stock_rule.py#L355-L360 However, if `sale_stock` is installed that `move_value` is reset to the value provided by the procurement values just a few lines bellow: https://github.com/odoo/odoo/blob/b9845f693af28e1d9fac773ae391b29f6831e982/addons/stock/models/stock_rule.py#L381-L384 because the `partner_id` field is part of the field name returned by the `_get_custom_move_fields`:
https://github.com/odoo/odoo/blob/b9845f693af28e1d9fac773ae391b29f6831e982/addons/sale_stock/models/stock.py#L173-L176
Since the `partner_id` value provided by the procurement values was `False`, it resets the the `partner_id` creation value to `False`.

### Fix:

As the flow relies on the value provided here:
https://github.com/odoo/odoo/blob/c4f8eb2824bef7348e3f94031140450daa4df651/addons/stock/models/stock_rule.py#L342-L349 when `sale_stock` is not installed but relies on the value of the procurement provided here:
https://github.com/odoo/odoo/blob/c4f8eb2824bef7348e3f94031140450daa4df651/addons/stock/models/stock_move.py#L1709 https://github.com/odoo/odoo/blob/c4f8eb2824bef7348e3f94031140450daa4df651/addons/stock/models/stock_move.py#L1674-L1677
if `sale_stock` is installed, it is necessary that both provide the same value to keep coherence in the flow. However, since the partner is will be expected to be set also via the procurement values, it is necessary to adapt the condition to which we will set a partner on the reception of the inter-company-transit:
https://github.com/odoo/odoo/blob/c4f8eb2824bef7348e3f94031140450daa4df651/addons/stock/models/stock_rule.py#L349 Which is the reason why we moved this line should be triggered only if no partner was set by the procurement values.

opw-6034309

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

Forward-Port-Of: odoo/odoo#254855

*: website_blog, website_event, website_sale

The interaction for filling the dynamic content of dynamic snippets did not run inside the iframe to preview the snippet to add. This is not an issue for the initial dynamic snippet, as they are filled with fake content. But when saving a custom snippet, the dynamic content is cleared, and they seem empty when previewed. This is the case since the [website builder refactor] as the previous builder re-used the preview of the initial snippet.

This commit adds the interaction to fill dynamic content in the preview iframe, and changes the interaction to avoid emptying the fake content from initial dynamic snippets during preview.

Steps to reproduce:
- Open website builder
- Add a dynamic snippet (for example "Events")
- Save the snippet as a custom snippet
- Click on "Custom" snippet category
- Bug: The preview for the custom snippet does not have the dynamic part (there is no event, just the title)

[website builder refactor]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2
task-5427353

Forward-Port-Of: odoo/odoo#253985
Forward-Port-Of: odoo/odoo#246328

***: test_discuss_full**

**Description of the issue this PR addresses:**
Thread unread counters should reflect the actual backend state 
as soon as Inbox messages are loaded, not only after a new bus 
notification is received.

**Steps to Reproduce:**
- Log in as User A and User B.
- Ensure User A preferences set to Handle in Odoo.
- From User B, mention User A in the chatter of a record.
- From User A, Open the messaging menu, counter for that related thread 
is correct.
- Refresh the page.
- Open the messaging menu again, the thread now shows a grey badge 
instead of the expected unread counter.

**Current behavior before PR:**
- When loading Inbox messages, related `mail.thread` records 
(such as project.task) did not include unread counters in the store payload. 
As a result, threads that already had unread messages appeared as (grey badge) 
after a refresh, leading to an incorrect counter state.

- Additionally, frontend-only counter adjustments could sometimes lead to 
inconsistent or even negative unread values due to missing initial sync.

**Desired behavior after PR is merged:**
- Threads with existing unread messages now receive the correct counter state, 
when Inbox messages are fetched.
- This also prevents inconsistent or negative counter values caused by 
frontend-only updates.
- This also ensures updating the `inbox query list` and corresponding `query count`:

task-[5474143](https://www.odoo.com/odoo/project/1519/tasks/5474143)

Before/After (**on refresh**):
<img width="461" height="55" alt="image" src="https://github.com/user-attachments/assets/2fc57aba-049c-4129-95b1-1d2b2770ac66" />

<img width="469" height="57" alt="image" src="https://github.com/user-attachments/assets/111d10bb-2aec-4711-8f5a-af7f332021d8" />



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

Forward-Port-Of: odoo/odoo#252611
Forward-Port-Of: odoo/odoo#247569

**Problem:**
When manually registering a payment using a Stripe SEPA Direct Debit token, the associated `account.payment` is immediately canceled, even though the Stripe transaction is in "Pending" status. Later, when Stripe confirms the transaction, the payment remains canceled, leading to subscription closures after 90 days of apparent non-payment.

**Steps to reproduce:**
1) Set a customer address to Belgium and add a SEPA Direct Debit payment token via Stripe.
2) Change the company currency to euro.
4) Create a manual invoice for that customer.
5) Pay the invoice using the pre-configured Stripe SEPA token.
6) Observe the `account.payment` is immediately canceled despite the transaction being "Pending".
7) When Stripe confirms the transaction, the payment stays canceled.

**Cause:**
In `account_payment.action_post()`, after sending the payment request, all payments whose transaction state was not `done` were canceled. For asynchronous payment methods like SEPA Direct Debit, the transaction starts in `pending` (not `done`), so the payment was wrongly canceled.

**Solution:**
- Only cancel payments whose transaction ended in a failure state (not in `done`, `pending`, or `authorized`), so pending/authorized payments stay in draft/in_process.

**NOTE**
In v19.2
the states naming got changed by this commit https://github.com/odoo/odoo/commit/34280f6e14e291ba4414eaf6d00d1cee7bbdac5b

so now a payment state is set to "paid" no "in_process" after the `payment.action_post()`

opw-5934381

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

Forward-Port-Of: odoo/odoo#253876