Currently, the recurring price table displays incorrectly when the user enables the one-time purchase option for a product.

**Steps to produce:**
* Install `website_sale_subscription` with demo data
* Products > Car Leasing > Recurring prices > Enable Accept One-time
* Go to that product's website page

**Observed behavior:**
The pricing table template [1] is appended inside the input radio button instead of replacing the entire pricing table.

**Root cause:**
* Initially, when the `sale_subscription_product_price` template is used, function [2] replaces the table inside `div` [3], which has the `plan_select` class.
* But  When one-time purchase is enabled, the template `subscription_one_time_sale` is used instead of `sale_subscription_product_price`.
* In that template, `div` [4] does not have the `plan_select` class.
* Because of this, the query selector [5] finds the first `plan_select` element inside `input` [6].
* As a result, function [2] renders the table inside that `input` element instead of the intended `div`.

**Solution:**
This commit ensures that:
* One time purchase price is changed dynamically based on variants.
* The pricing table is displayed correctly for both service and
  goods type products.
* The radio button selection works correctly by adding classes to the template
  and modifying its interaction accordingly.

| Before 'Service' type product page | After  'Service' type product page|
|--------|--------|
| <img width="1855" height="928" alt="image" src="https://github.com/user-attachments/assets/d662fbf5-cfce-45c5-b14c-043e982c63a6" /> | <img width="1851" height="933" alt="image" src="https://github.com/user-attachments/assets/8e510b27-6917-43bc-ac5d-b01ff1b187ad" />|

|  Before 'Goods' type product page | After  'Goods' type product page |
|--------|--------|
| <img width="1852" height="931" alt="image" src="https://github.com/user-attachments/assets/b9aa68e7-beef-413c-b99e-a71937e35e10" />| <img width="1851" height="932" alt="image" src="https://github.com/user-attachments/assets/d768edd9-2169-4d43-ac59-9893b55d5bcd" /> | 

[1]:
https://github.com/odoo/enterprise/blob/ae2f3a8062a0509db565e7bab2376a001fa047ae/website_sale_subscription/static/src/xml/pricing_view.xml#L21-L63
[2]:
https://github.com/odoo/enterprise/blob/ae2f3a8062a0509db565e7bab2376a001fa047ae/website_sale_subscription/static/src/js/variant_mixin.js#L32-L36
[3]:
https://github.com/odoo/enterprise/blob/77423e62d5b74d73cad86bf81fdfee2bea3ef2d1/website_sale_subscription/views/templates.xml#L61
[4]:
https://github.com/odoo/enterprise/blob/ae2f3a8062a0509db565e7bab2376a001fa047ae/website_sale_subscription/views/templates.xml#L130
[5]:
https://github.com/odoo/enterprise/blob/7837a4497759dc9dd75aeac30083266798c5ce59/website_sale_subscription/static/src/js/variant_mixin.js#L18-L20
[6]:
https://github.com/odoo/enterprise/blob/ae2f3a8062a0509db565e7bab2376a001fa047ae/website_sale_subscription/views/templates.xml#L138


opw-5380240

Forward-Port-Of: odoo/enterprise#102427

Currently, fields added using XPath expressions before or after the `VAT` field 
(such as `IE`, `IM`, and `SUFRAMA` from `l10n_br`) lose their labels and helpers in 
the Contacts form, making them hard to identify.

**Steps to reproduce:**
- Install the `l10n_br` module and switch to a `BR company`.
- Go to Contacts and open a contact form.
- Observe the Brazilian identification number fields (`IE`, `IM`, `SUFRAMA`).

**Obeservation:**
Missing labels and helpers for fields added around the `VAT` field in 
the `res.partner` form.

**Root Cause:**
After commit [1], `account.view_partner_property_form` inherits from
`product.view_partner_property_form` at [2], whose default priority (16) 
causes it to be applied after `base_vat.view_partner_base_vat_form`, 
which has priority (15) at [3].

As a result, the `base_vat` module moves the `VAT` field into the
`vat_vies_container` div. Consequently, any subsequent XPath
expressions targeting the `vat` field with position `before` or
`after`, when the view is inherited from `account.view_partner_property_form`, 
are applied inside this container instead of the original form layout.

The issue is not limited to the Brazilian localization, it impacts any module 
that inherits from the `account.view_partner_property_form` views and relies 
on XPath expressions positioned around the `VAT` field.

**Fix:**
This commit ensures that fields added before or after the VAT field remain
properly labeled and identifiable across all modules by assigning a higher
priority to `product.view_partner_property_form` than to
`base_vat.view_partner_base_vat_form`.

**Before:**
<img width="1908" height="616" alt="5443833_before" src="https://github.com/user-attachments/assets/f7d0819d-38bd-4fe8-8a22-5e22b342cd32" />

**After:**
<img width="1909" height="703" alt="5443833_after" src="https://github.com/user-attachments/assets/b205cb87-64ba-49fd-91c4-c20908d21429" />

[1]:
https://github.com/odoo/odoo/commit/4bff48d8233a9c1338252725f92ffcf580bd2b9d

[2]:
https://github.com/odoo/odoo/blob/229c2737edee601552ccceeed8602ec0e4686596/addons/account/views/partner_view.xml#L191

[3]:
https://github.com/odoo/odoo/blob/229c2737edee601552ccceeed8602ec0e4686596/addons/base_vat/views/res_partner_views.xml#L4-L26

opw-5443833

When a user sets an invalid video link for a slide, a traceback occurs.

Steps to reproduce the error:
- Install ``website_slides`` module with demo data
- Go to Website > Courses > Open Taking care of Trees course
- Add Content > Video > Add valid video link (ex. https://www.youtube.com/shorts/SXHMnicI6Pg) > Save and Publish > Delete
- Repeat above step
- Add content > Video > Add any text in video link > Save and Publish

Traceback:
```py
AssertionError: Could not find all values of slide.slide(12,) to flush them
```

https://github.com/odoo/odoo/blob/7bbfb207f8699973f8580ea18821f82b1a83e149/addons/website_slides/controllers/main.py#L1363-L1372
New record is created using ``new()`` to fetch external metadata for the slide.
This record only exists in memory and is not stored in the database.
When the video link is invalid, ``video_source_type`` is False, and the code attempts to ``unlink()`` the slide.
Unlinking the record triggers field recomputations,
and it will lead to the above error when flushing the new record.

ref: https://github.com/odoo/odoo/commit/71233fa2cb8984b65f8e7ac55405fdbc054756a0

sentry-6964031088

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

Forward-Port-Of: odoo/odoo#235099

**Steps to reproduce:**
* Install the *purchase_stock* module
* Create new Product category.
* In the category, set the **Costing Method** to *Average (AVCO)*.
* Create a new product and assign a created product category. 
* Create a new Purchase Order.
  * Add a Purchase Order Line with the created product.
  * Set **Quantity** to 10.
  * Set **Unit Price** to 100.
  * Set **Discount** to 10%.
* Confirm the Purchase Order.
* Validate the generated receipt.
* Open the product form and check the *standard_price*(Cost) field.

**Observed behavior:**
The product standard price is updated to **100**, calculated from  the undiscounted unit price (1000 / 10), ignoring the discount applied  on the purchase order line. The expected value is *90* (900/10).

**Cause:**
With the new inventory valuation logic in v19.0, the standard price is updated via *_update_standard_price*, which calls *_run_avco* which uses the stock move *value* field set by *_get_value_from_quotation*:
https://github.com/odoo/odoo/blob/71195624008f8c1ba8b10e1b04433e34e08fb540/addons/stock_account/models/product.py#L340
However, the *_get_value_from_quotation* relies on *_get_stock_move_price_unit*, which returns the unit price **without considering the discount**, leading to an incorrect move value for AVCO computation.

**Note:** 
Prior to 19.0, the `price_unit` of the move was calculated in the `_get_price` unit using the `_get_gross_price_unit` using the discounted value of the line:
https://github.com/odoo/odoo/blob/24db73743d8bb4d678af7efb4d78a019e0953395/addons/purchase_stock/models/stock_move.py#L152-L154
https://github.com/odoo/odoo/blob/24db73743d8bb4d678af7efb4d78a019e0953395/addons/purchase/models/purchase_order_line.py#L383-L387
It should still be the case here as there is no discounted_unit_price on the move and, since we do not rely on the `_get_gross_price_unit` anymore, we should adapt the relative call:
https://github.com/odoo/odoo/blob/090c5a4d55e3fcd1b2840bc8afaed49efc8745d4/addons/purchase_stock/models/stock_move.py#L214-L218
https://github.com/odoo/odoo/blob/090c5a4d55e3fcd1b2840bc8afaed49efc8745d4/addons/purchase_stock/models/purchase_order_line.py#L238-L243


---
opw-5409226

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

Forward-Port-Of: odoo/odoo#241273

Currently, an error occurs when signing a document containing a non-mandatory selection field that is left unchanged.

**Steps to Reproduce:**
1. Install the Sign module.
2. Add a _Selection_ field to a document template and define at least one option. Make sure the field is not mandatory.
3. Click **"Sign Now"**, then **"Validate & Send Completed Document"** without modifying the selection field.

**Error:**
`ValueError - invalid literal for int() with base 10: 'Selection125340'`

Cause:
After this commit [1], `textareaApplyLineBreak()` is executed for all item types. For selection type, this updates the item value from `undefined` to a generated string (e.g. **Selection132**), which later causes an invalid integer conversion during validation.

**Fix:**
This commit ensures `textareaApplyLineBreak` is only applied to textarea items and not to other field types.

[1]: https://github.com/odoo/enterprise/commit/c1bfc84505ca8053a073c23b6a7b569021e9ca0c

sentry-7089120038
opw-5402249

Forward-Port-Of: odoo/enterprise#102124

Currently when the user adds an alternate product with a variant, the product title shows the variant name instead of the template name, even when `Show Variants` is disabled.

**Steps to produce:**
* Install `website_sale`
* products > Select any product > sales
* Add any product with variant to alternate products
* Go to that product's website page and scroll to alternate products section.

**Observed Behavior:**
* Product variant names are shown instead of product template names, even though `Show Variants` is disabled.

**Root cause:**
* This happens because loading the alternative product snippet calls `_get_products` [1], which then calls`_filter_records_to_values`. That function calls `_get_combination_info` [2],causing the display names to be updated to the combination display name.

**Solution:**
 Show the product template name instead of the combination name when `Show Variants` is disabled, by using only product templates and updating the product template display name computation to account for `display_default_code`, to ensure the internal reference remains hidden when it is set to `False`.

**Before:**
<img width="1847" height="932" alt="image" src="https://github.com/user-attachments/assets/81ffaf94-d63d-4e2c-9b46-dd369d34bc7b" />

**After:**
<img width="1847" height="932" alt="image" src="https://github.com/user-attachments/assets/4a6d3fa6-541d-4091-9691-e8b10f542833" />

[1]:
https://github.com/odoo/odoo/blob/c4448d2e16e6f4b0b5ea99f6e883cb69d226cfba/addons/website_sale/models/website_snippet_filter.py#L173-L190 
[2]:
https://github.com/odoo/odoo/blob/c4448d2e16e6f4b0b5ea99f6e883cb69d226cfba/addons/website_sale/models/website_snippet_filter.py#L132

opw-5365320

Forward-Port-Of: odoo/odoo#240325

Description of the issue/feature this PR addresses:
This PR updates the company filtering logic in account balance computations to support Odoo's branch hierarchy. In multi-branch environments, a parent company should be able to see the aggregated balances of its child branches. Currently, the strict equality operator prevents this consolidation, creating a discrepancy between the expected "Global" view and the displayed balance.

Current behavior before PR:
The _compute_current_balance method in account_account.py uses the = operator for the company_id domain: domain=[('account_id', 'in', self.ids), ..., ('company_id', '=', self.env.company.id)]

This restricts the balance calculation exclusively to the current active company, excluding any transactions made in its branches (child companies), even when the user is positioned at the parent level.

Desired behavior after PR is merged:
The operator is changed to child_of. When a user is in a parent company/branch, the current_balance of the account will include the sum of all journal entries from that company and all its descendants in the hierarchy. This ensures consistency with how other parts of Odoo (like https://github.com/odoo/enterprise/blob/e29aadef1a81c662d9a4d33879b440dbe4390c0b/account_followup/models/res_partner.py#L230) handle company-related domains.





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

Forward-Port-Of: odoo/odoo#242576

**Problem:**
When ordering a combo product, you can order more products than the
combo requires, which will the add *base_price* to the combo price.
The problem is that when changing the preset, like going from eat in
to delivery, the pricelist is reconfigured, and it does not take the
extra products from the combo into account. This means that the price
will go back to the combo's price without the extra products.

**Steps to reproduce:**
- Have a combo that can take on multiple free products and has a limit above this free product number
- Order more than the free quantity
- Change the preset (from eat in to delivery)
- The price is recomputed without taking the extra products into account

**Why the fix:**
The extra articles were not accounted for when changing the pricelist,
meaning they would end up free and the price would change. We now
make a separation between the free products (that are from the combo) and
the extra products. The extra products cost the *base_price* of said combo.

To do that, we need to get the extra lines from the combo, which are the
products that are not free in the case where there are more products
selected in the combo than free products defined in the definition of
the combo. To make that happen, we add the non free lines to the
extra lines list once we have at least as many free products as
defined in the combo definition.

In the case where the quantity of a product is greater than the number
of free items, the lines are automatically split. Meaning if we have
a combo with 2 free items but we order 3, we will have a line with
a quantity of 2 and another line with a quantity of 1. In that case,
the first line will be free, but the second line will be an extra.
This logic is implemented here https://github.com/odoo/odoo/blob/0087cc96b2d2190ab107c3d50d3bdd48f7a687e9/addons/point_of_sale/static/src/app/components/popups/combo_configurator_popup/combo_configurator_popup.js#L88-L106
Which is then retrieved here to make the separation in the combo's price
https://github.com/odoo/odoo/blob/0087cc96b2d2190ab107c3d50d3bdd48f7a687e9/addons/point_of_sale/static/src/app/services/pos_store.js#L879

opw-4885574

Forward-Port-Of: odoo/odoo#241689
Forward-Port-Of: odoo/odoo#217082