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

**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

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

Commit 04155a0 correctly increased the threshold for the VP7 line
of the monthly tax report from 25.82€ to 100.00€. However, a
subsequent commit (https://github.com/odoo/odoo/commit/51a72ab42d118d6fb0eb3e3545a09e10019b9140) accidentally reverted this change to
the outdated value.

This commit restores the threshold to the expected value of 100.00€.

---

The previous fix in https://github.com/odoo/odoo/commit/4e831999ed06e0e3c2f380414c5949db645f2f19 attempted to correct VP6 (VAT due/deductible)
but relied on an incorrect assumption regarding debit signs.

In the Italian tax report, values should remain positive regardless of
whether they are debits or credits. Displaying debits as negative caused:
1. Incorrect visual representation in the report columns.
2. Inconsistent totals for VP14 (VAT payable).

This commit ensures all debit column values are displayed as positive
and restores the correct calculation logic for the report totals.

opw-5357719
opw-5411706
opw-5421779

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

Forward-Port-Of: odoo/odoo#240705

### Steps to reproduce:

- Create a bom for a product with 2 component lines:
    - 1 x COMP1
    - 1 x COMP2
- Create an MO for your product (do not confirm it)
- Delete the second bom line of the bom
- On the draft MO, click on `update bom`
#### > This automatically modifies the `move_raws` of the MO but the un-linked move raws were neither deleted nor cancelled as shown by the move analysis

### Cause of the issue:

Clicking on `update bom` will launch a call of the `action_update_bom` which will itself call the `_link_bom` to update the record: https://github.com/odoo/enterprise/blob/ac3f333d97eda5c86a0813490ac6204d4ec5721f/mrp_plm/models/mrp_production.py#L73-L80 https://github.com/odoo/odoo/blob/98da30375a5ae50a77d848b838781aa7247bd362/addons/mrp/models/mrp_production.py#L2406-L2418 Now the issue is that the `bom_id` is set to `False` before the value of the `move_raw_ids` and `workorder_ids` are stored to be unlinked in the `moves_to_unlink` and `workorders_to_unlink` variable. Now, the issue is that the `bom_id` is a dependency of both compute methods: https://github.com/odoo/odoo/blob/98da30375a5ae50a77d848b838781aa7247bd362/addons/mrp/models/mrp_production.py#L745-L746 https://github.com/odoo/odoo/blob/98da30375a5ae50a77d848b838781aa7247bd362/addons/mrp/models/mrp_production.py#L563-L564 in particular, `moves_to_unlink` will always be an empty record set and the value of the `workorders_to_unlink` might be unreliable.

opw-5243203

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

Forward-Port-Of: odoo/odoo#242132
Forward-Port-Of: odoo/odoo#239654

When creating or editing Peruvian purchase invoices/credit notes, the l10n_latam_document_number field is formatted with zfill(8) (e.g., "F01-100" becomes "F01-00000100"), but the name field was not synchronized, causing data inconsistencies between these fields.

Steps to reproduce:
1. Create a purchase invoice for a Peruvian company
2. Select a document type (Factura, Boleta, or Credit/Debit Note)
3. Enter a document number like "F01-100"
4. Save the record
5. Observe that l10n_latam_document_number shows "F01-00000100" but name field may show a different format

This fix ensures that after formatting the document number, the name field is synchronized with the correctly formatted value, preventing inconsistencies in vendor invoices and reports.

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#241948

Steps to reproduce:
====================
- Go to the website in chrome
- Create a Image Wall (gallery)
- Add a lot of images. See attachments for a .zip file in task to test it.
- Try to change the display mode or number of column

-> An error will appear when the cursor get on the dropdown options.

Cause:
======
In Google Chrome, calling img.decode() on a large set of images simultaneously (e.g., in an image wall) can result in `EncodingError: The source image cannot be decoded for some images`. This is a known Chromium issue (See [1]) where the browser's image decoder gets overwhelmed or hits a concurrency limit, causing it to reject valid images.

The current implementation uses Promise.all(imgLoaded), which utilizes a "fail-fast" mechanism. Consequently, if a single image fails to decode due to this browser limitation, the entire promise rejects immediately. This unhandled rejection interrupts the execution flow, preventing the display mode or column options from functioning correctly when the user interacts with them.

Solution:
========
Replace `Promise.all(imgLoaded)` with `Promise.allSettled(imgLoaded)`.

Unlike `Promise.all`, `Promise.allSettled` waits for all promises to finish regardless of whether they succeeded or failed.

[1]: https://issues.chromium.org/issues/40261318

opw-5249130

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

Forward-Port-Of: odoo/odoo#240062

Issue:
A TaxSubtotal node was blocking the XML validation for peppol invoices with Cash Rounding

Step to reproduce:
1. Select BE Company CoA
2. Enable Cash Rounding in the settings
3. Create a cash rounding method (in the settings where cash rounding can be enabled):
   - precision `1.00`
   - strategy: Add a rounding line
   - profit / loss account: any
4. Create an invoice
   - Set a Belgian partner (e.g. "BE Company CoA" is okay)
   - Set the cash rounding method from step 2
   - Single Line with price=70.00€ and a 21% tax
5. The total should be 85.00 € (84.70 € w/o the rounding) In the journal items there should be the following non-payment term items:
   - 70.00€ base
   - 14.70€ tax
   -  0.30€ rounding
6. Confirm & Send (with PEPPOL)

Current Behavior:
Look at the UBL BIS 3 XML in the `Invoice` element
   - `TaxTotal/TaxAmount`: 14.70€
   - `TaxTotal/TaxSubtotal/TaxableAmount`: 70.00€
   - `TaxTotal/TaxSubtotal/TaxAmount`: 14.70€
   - `TaxTotal/TaxSubtotal/TaxableAmount`: 0.30€
   - `TaxTotal/TaxSubtotal/TaxAmount`: 00.00€
   - `TaxTotal/TaxSubtotal/TaxCategory/TaxExemptionReason`: "Exempt from tax"
   - `LegalMonetaryTotal/TaxExclusiveAmount`: 70.00€
   - `LegalMonetaryTotal/TaxInclusiveAmount`: 84.70€
   - `LegalMonetaryTotal/PayableRoundingAmount`: 00.30€
   - `LegalMonetaryTotal/PayableAmount`: 85.00€ This fails validation `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 [is equal to: `BT-116 = sum(BT-131) - sum(BT-92) + sum(BT-99)` i.e. `VAT category taxable amount = Invoice net - allowance + charge`] where all the VAT category codes (BT-151, BT-95, BT-102) are "Exempt from VAT""

Expected behavior:
Look at the UBL BIS 3 XML in the `Invoice` element
   - `TaxTotal/TaxAmount`: 14.70€
   - `TaxTotal/TaxSubtotal/TaxableAmount`: 70.00€
   - `TaxTotal/TaxSubtotal/TaxAmount`: 14.70€
   - `LegalMonetaryTotal/TaxExclusiveAmount`: 70.00€
   - `LegalMonetaryTotal/TaxInclusiveAmount`: 84.70€
   - `LegalMonetaryTotal/PayableRoundingAmount`: 00.30€
   - `LegalMonetaryTotal/PayableAmount`: 85.00€

Solution:

Per the calculation of the VAT category taxable amount (BT-116). There should have a TaxSubtotal for tax Category having invoice lines.
https://docs.peppol.eu/poacc/billing/3.0/bis/#_calculation_of_totals 
As invoice lines should contain their item name. Rounding line won't have one.
https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-25/
As rounding appear in the LegalMonetaryTotal, removing the related TaxSubtotal doesn't remove information.
https://docs.peppol.eu/poacc/billing/3.0/bis/#_element_for_rounding_amount_the_payableroundingamount

Rounding base_lines are removed from `vals['base_lines']` as they need to have a product label. https://github.com/odoo/odoo/blob/366d7122ee30e16c157d026363b731c066a564c5/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_bis3.py#L305-L310

As `_ubl_add_values_payable_rounding_amount` needs rounding lines within base_lines and `_ubl_add_values_tax_totals` shouldn't have them, this commit exchanges their processing order.

This commit also:
- fix the test file `test_invoice_cash_rounding_add_invoice_line.xml` as it failed the XML validation (BR-E-08).

opw-5434335


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

Forward-Port-Of: odoo/odoo#241717

Previously, generating the budget.report table was necessary to trigger _compute_all for budget.line fields. This table was built using three separate queries with a UNION operator. Because of the UNION, any filtering (like on specific budget_line_ids) happened after the full, unfiltered table was generated.

This post-filtering caused slowness, especially in nested loop joins with large tables like account.analytic.line. This commit optimizes performance by pushing the filter condition (using specific budget_line_ids) directly down into the three underlying queries. This reduces the number of budget.line records processed, speeding up joins and overall computation.

The benchmark below is done on a database that has **66396** `budget.line` records and **928567** `account.analytic.line` records. Opening a budget report for a specific year, only applied the filter with **40** `budget.line` records.

| Scenario | Execution Time |
| :--- | :--- |
| **Before this Commit** | **60.00 seconds**
| **After this Commit** | **1.84 seconds**

opw-5150569

Forward-Port-Of: odoo/enterprise#102918
Forward-Port-Of: odoo/enterprise#99096

### [FIX] purchase_mrp, mrp: correct BoM Kit valuation with nested kits

#### Issue:
When purchasing a BoM Kit (50/50) containing others BoM Kits (50/50), cost share was applied at each level (50% instead of 25%), leading to overvaluation (e.g., 200% total instead of 100%)

#### Cause:
`cost_share` was always applied fully during BoM explosion and as a portion of the full price on `_get_unit_price()`

#### Other bug fixed:
Fix `_get_cost_share()` to correctly return 0 when BoM total cost_share already equals 100%

#### Requirement:
AVCO (Average Cost) must be enabled on all components/BoMs

#### Steps to reproduce:
1. Recreate that hierarchy with AVCO Products
- A kit "Testing Kit Complete" containing:
-- "Component01", cost share 50%
-- A kit "Testing Kit 1", cost share 50%:
--- "Component02", cost share 50%
--- "Component03", cost share 50%
2. Create and validate a Purchase Order for "Testing Kit Complete" (unit price: 1000)
3. Receive the products
4. Go in Inventory > Reporting > Valuation and search for Component
5. All 3 components are set to 500, instead of Component01: 500 / Component02: 250/ Component03: 250

opw-4806023


### [FIX] purchase_mrp: correct BoM valuation with product variants or optional lines

#### Issue:
BoM valuation ignores variant-specific lines and does not skip lines with quantity 0

#### Cause:
The code only checks that the BoM adds up to 100%
But this can cause issues with variants that do not include all products or with optional lines
As a result, the total valuation may be incorrect

#### Steps to reproduce:
1. Recreate a kit hierarchy with AVCO products:
   - Kit "Variant Kit" (Variant Color: White and Wood) containing:
     -- "Component01", cost share 0%, only for variant White
     -- "Component02", cost share 0%
2. Create and confirm a Purchase Order for "Variant Kit" (variant: Wood, unit price: 1000)
3. Receive the products
4. Go to Inventory > Reporting > Valuation and search for the components
5. Only Component02 appears with 500$, so only half of the total value is shown

opw-4806023
opw-5085457

Forward-Port-Of: odoo/odoo#240425
Forward-Port-Of: odoo/odoo#218326

In the barcode application, scanning a picking order containing a kit product variant with packaging will raise a Traceback.

### Steps to reproduce:

1. Enable packagings on inventory configuration.
2. Create a product, that as a least 2 variants.
3. Add a packaging to one of the variants.
4. Create a BoM for created product (kit type).
5. Create a picking order for the variant with packaging.
6. Print the picking operation to scan the code through barcode.
7. Go to barcode and try to scan it, this will trigger the traceback.

### Cause of the issue:
Scaning a barcode will call get_barcode_data during this call it will retrieve the information about the picking order and call _get_stock_barcode_data:
https://github.com/odoo/enterprise/blob/f2dd6326c2084ed467c3e4c3e9d931f41309ad79/stock_barcode/controllers/stock_barcode.py#L91
_get_stock_barcode_data will obtain the packaging methode for the products.
https://github.com/odoo/enterprise/blob/f2dd6326c2084ed467c3e4c3e9d931f41309ad79/stock_barcode_mrp/models/stock_picking.py#L13-L16
since in our use case the product has variant the packaging information is not inside product_tmpl_id.packaging_ids and thereof it will not retrieve the packaging information.

### Fix:
We don't need to use product_tmpl_id.packaging_ids because of its compute and set methods (and the fact that the product_variant_ids field is required), the product_tmpl_id.packaging_ids will always be included in the product_tmpl_id.product_variant_ids.packaging_ids:
https://github.com/odoo/odoo/blob/eb88370e2fc1887e8c88dfd8dbeadce23bb7abe5/addons/product/models/product_template.py#L430-L441
our fix will allow for packaging in the variant to be considered when there is more than only one variant.

opw-4852875

Forward-Port-Of: odoo/enterprise#103155
Forward-Port-Of: odoo/enterprise#87867

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

**Steps to reproduce:**
- Create a combo including products with different variants
- The variants should be set to "Instantly"
- Go to PoS and click on that combo
- When confirming, the lines do not show the selected variant
- The ticket on the receipt screen does not show it either

**Why the fix:**
We were trying to map the combo lines using the line's configuration, but the configuration did not always contain the needed information, in this case the attribute_value_ids. This happens because when clicking on a combo, we are setting the configuration as the configuration popup is displaying, meaning we do not know which variants are going to be chosen.

Instead, we now access the correct variants using the current combo line directly if the configuration is not set.

An existing test had to be changed because before this fix, as we did not care for variants in certain cases, we did not
add the price_extra from the variant to the combo's price, which seems to be the behavior we want.

opw-5392530

Changing the analytic account on the journal entry generated by a company-paid expense creates an unwanted auto-balancing line.

## Steps to reproduce
1. Create an expense paid by the company.
2. Confirm and generate the expense report.
3. Reset the expense’s journal entry to draft and add an analytic account on the first line.
→ An auto-balancing line is added to the entry, and the remaining lines are incorrectly debited.

## Cause
For company-paid expenses, the generated journal entry represents a *payment* rather than an *invoice*.
In `_prepare_product_base_line_for_taxes_computation`, this causes the method to use `product_line_amount_currency` as the price unit, which excludes taxes.

However, in `hr_expense`, the same method always defines `special_mode['total_included'] = False`.
This combination leads `_get_tax_details` to call `_eval_tax_amount_price_included` instead of `_eval_tax_amount_price_excluded`, reapplying the tax on the lines.
As a result, the move becomes unbalanced and Odoo generates an auto-balancing line to compensate.

## Solution
Keep the special mode as *total excluded* for payments generated by company-paid expenses, since their tax and product lines are already handled separately in the corresponding `account.move`.

**opw-5166707**


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

Forward-Port-Of: odoo/odoo#241545
Forward-Port-Of: odoo/odoo#233841

Issue:
A TaxSubtotal node was blocking the XML validation for peppol invoices with Cash Rounding

Step to reproduce:
1. Select BE Company CoA
2. Enable Cash Rounding in the settings
3. Create a cash rounding method (in the settings where cash rounding can be enabled):
   - precision `1.00`
   - strategy: Add a rounding line
   - profit / loss account: any
4. Create an invoice
   - Set a Belgian partner (e.g. "BE Company CoA" is okay)
   - Set the cash rounding method from step 2
   - Single Line with price=70.00€ and a 21% tax
5. The total should be 85.00 € (84.70 € w/o the rounding) In the journal items there should be the following non-payment term items:
   - 70.00€ base
   - 14.70€ tax
   -  0.30€ rounding
6. Confirm & Send (with PEPPOL)

Current Behavior:
Look at the UBL BIS 3 XML in the `Invoice` element
   - `TaxTotal/TaxAmount`: 14.70€
   - `TaxTotal/TaxSubtotal/TaxableAmount`: 70.00€
   - `TaxTotal/TaxSubtotal/TaxAmount`: 14.70€
   - `TaxTotal/TaxSubtotal/TaxableAmount`: 0.30€
   - `TaxTotal/TaxSubtotal/TaxAmount`: 00.00€
   - `TaxTotal/TaxSubtotal/TaxCategory/TaxExemptionReason`: "Exempt from tax"
   - `LegalMonetaryTotal/TaxExclusiveAmount`: 70.00€
   - `LegalMonetaryTotal/TaxInclusiveAmount`: 84.70€
   - `LegalMonetaryTotal/PayableRoundingAmount`: 00.30€
   - `LegalMonetaryTotal/PayableAmount`: 85.00€ This fails validation `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 [is equal to: `BT-116 = sum(BT-131) - sum(BT-92) + sum(BT-99)` i.e. `VAT category taxable amount = Invoice net - allowance + charge`] where all the VAT category codes (BT-151, BT-95, BT-102) are "Exempt from VAT""

Expected behavior:
Look at the UBL BIS 3 XML in the `Invoice` element
   - `TaxTotal/TaxAmount`: 14.70€
   - `TaxTotal/TaxSubtotal/TaxableAmount`: 70.00€
   - `TaxTotal/TaxSubtotal/TaxAmount`: 14.70€
   - `LegalMonetaryTotal/TaxExclusiveAmount`: 70.00€
   - `LegalMonetaryTotal/TaxInclusiveAmount`: 84.70€
   - `LegalMonetaryTotal/PayableRoundingAmount`: 00.30€
   - `LegalMonetaryTotal/PayableAmount`: 85.00€

Solution:

Per the calculation of the VAT category taxable amount (BT-116). There should have a TaxSubtotal for tax Category having invoice lines.
https://docs.peppol.eu/poacc/billing/3.0/bis/#_calculation_of_totals 
As invoice lines should contain their item name. Rounding line won't have one.
https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/BR-25/
As rounding appear in the LegalMonetaryTotal, removing the related TaxSubtotal doesn't remove information.
https://docs.peppol.eu/poacc/billing/3.0/bis/#_element_for_rounding_amount_the_payableroundingamount

Rounding base_lines are removed from `vals['base_lines']` as they need to have a product label. https://github.com/odoo/odoo/blob/366d7122ee30e16c157d026363b731c066a564c5/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_bis3.py#L305-L310

As `_ubl_add_values_payable_rounding_amount` needs rounding lines within base_lines and `_ubl_add_values_tax_totals` shouldn't have them, this commit exchanges their processing order.

This commit also:
- fix the test file `test_invoice_cash_rounding_add_invoice_line.xml` as it failed the XML validation (BR-E-08).

opw-5434335


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

Forward-Port-Of: odoo/odoo#241717

Issue
-----
When the SO and the company use different currencies, the picking currency is correctly set to the SO's but the amount is still computed using the company's currency.

Example:
	Sale in EUR, Company in USD and 1.5 EUR = 1 USD rate.
	Sell for 15 EUR of products => the delivery picking shows 10 EUR

Steps to reproduce
-----
- Activate EUR currency at 1.5 EUR = 1 USD rate
- Setup company in USD
- Setup INTL FEDEX delivery method
- Create a dummy product with a 10 USD sale price
- Create a pricelist using the EUR currency
- Create a sale for some INTL client
	- set pricelist to EUR
	- add dummy product
	- add INTL FEDEX shipping
	- confirm the sale
- Confirm the linked delivery

> Message in chatter shows a price of 10 EUR instead of 15 EUR

Cause
-----
The problem is with the `carrier_price` field of `stock.picking`.

https://github.com/odoo/odoo/blob/7c443175f563b9b12a7b8f638524f7f625962dc2/addons/stock_delivery/models/stock_picking.py#L21

The value is set by

https://github.com/odoo/odoo/blob/7c443175f563b9b12a7b8f638524f7f625962dc2/addons/stock_delivery/models/stock_picking.py#L155

which gets its' value from the response of

https://github.com/odoo/enterprise/blob/0aea72c8db3067073afe1f89dfddf2b43d9392e9/delivery_fedex_rest/models/delivery_fedex.py#L157

We then go through

https://github.com/odoo/enterprise/blob/0aea72c8db3067073afe1f89dfddf2b43d9392e9/delivery_fedex_rest/models/fedex_request.py#L382

where we call

https://github.com/odoo/enterprise/blob/0aea72c8db3067073afe1f89dfddf2b43d9392e9/delivery_fedex_rest/models/fedex_request.py#L484

The problem is that in `_decode_pricing` we take the first line matching the `rateType` with no regard to the currency of the rate

https://github.com/odoo/enterprise/blob/0aea72c8db3067073afe1f89dfddf2b43d9392e9/delivery_fedex_rest/models/fedex_request.py#L594-L598

we should also filter to ensure the rate matches the order's specified currency.

-----
Ticket:
opw-5419724

Forward-Port-Of: odoo/enterprise#103232

Fix an incorrect flow when creating a Manufacturing Order through the Barcode app.

Steps to reproduce:
- Disable tracking in Settings
- Create a BOM for product Table with components Wood and Screws
- In the Barcode app, go to Manufacturing
- Click New > Add product and select Table
- Click Confirm -> Components are not added after the Table line

The issue occurs because `set_qty_producing` is called even when `lot_producing_id` is undefined, leading to a call to `_set_quantity_done` who will delete Stock Move Line since quantity done is 0. So, since SML was deleted, the `move_raw_line_ids` will also be affected.

This happens when tracking is disabled, causing the condition `lineRecord.data.lot_producing_id != this.env.model.record.lot_producing_id` to evaluate as true (undefined != false), which triggers `set_qty_producing`.

This fix ensures that `lot_producing_id` is defined before performing the comparison.

opw-5165163

Forward-Port-Of: odoo/enterprise#99735
Forward-Port-Of: odoo/enterprise#98440

## Current behaviour:
When validating a delivery, Odoo sends data to Starshipit. If label creation fails, the module deletes the created order.

## Expected behaviour:
If label creation fails, the Starshipit order should remain. Users should be able to fix data in Starshipit and retry validation in Odoo without losing the existing order.

## Steps to reproduce:
1. Validate a delivery order integrated with Starshipit.
2. Trigger a label generation failure (e.g., bad address).
3. Observe that the created Starshipit order is deleted.

## Cause of the issue:
The integration treats label creation failure as a fatal step and cleans up the previously created Starshipit order.

## Fix:
Do not delete the Starshipit order on label failure. When the user retries validation, first check Starshipit for an order matching the unique reference. If found, reuse it and continue with label creation and manifest. If not found, create a new Starshipit order as usual.

## Additional note:
The _() wrapper in the error line was removed because
the Starshipit service has no env or language context.
Since translations cannot be resolved there, Odoo raised a warning.
Removing _() avoids this warning and keeps the error clean.

opw-5306979

Forward-Port-Of: odoo/enterprise#103480
Forward-Port-Of: odoo/enterprise#101174

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

Before this commit, whenever we called `/ai/generate_response` from the fron-end we were catching any potential exceptions and calling the `ai/post_error_message`. The `post_error_message` function called from that controller endpoint would take the exception message, and ask the AI to explain the error to the user without the use of technical terms.

The problem with this approach is two-fold.
Firstly, in the `post_error_message` method, we use the `generate_response` method in order for the AI to beauty-fy the error message. But, the `post_error_message` method is called when catching exceptions of the `generate_response` method. Thus, the exception is caught, a nice message is posted in the chat, but then a traceback is shown regardless.
Secondly, beautifying the error messages makes it more difficult for end users to understand what could be going wrong and making it also more difficult for our support to help them out.

In this commit, we removed the `post_error_message` flow. We move the try-except to the `_generate_response_for_channel` method and if the user is an internal user we let the exception bubble up. If not (for website users on livechat), a generic message will be posted on the chat.

task-5177169

Forward-Port-Of: odoo/enterprise#97516

This commit fixes an issue in the Salary Calculator where all fields were displayed as empty when selecting an employee with a resource_calendar_id set.

Steps to Reproduce :
	First Change to either the default company (MyCompany) or Demo Belgian company
	Payroll -> Employee -> Salary Calculator -> choose an employee.

Bug : All fields in the Salary Calculator view are empty (evaluated as False).

Root Cause :

Inside _compute_salary, the method _generate_salary_simulation_payslip writes on payslip.version_id using:

payslip.version_id.write(new_payslip_vals)

Because the is_simulation_offer key was missing from the context, this write triggered a full payslip computation, generating payslip lines. During this computation, compute_sheet() performs an unlink() on existing payslip lines. Since the Salary Calculator view fields are only cached at that point, the unlink causes the cached values to be lost, resulting in all fields being evaluated as False.

Fix : Ensure that is_simulation_offer is present in the context when writing to payslip.version_id, preventing payslip line generation and avoiding the unintended unlink() during salary simulation.

This PR references this one odoo/enterprise#102371

Task - 5387155

Forward-Port-Of: odoo/enterprise#102884

Steps to reproduce:
-------------------
1. Install hr_holidays
2. Create a public holiday on 9th jan
3. Set an employee's working schedule to a flexible 40h/week calendar
4. Create a time off request from Jan 4th → Jan 10th
5. Observe the displayed duration

Issue:
------
The leave duration is displayed as 5 days instead of 4. 
This happens because public holidays are not correctly accounted for
within the work intervals.

Cause:
------
Work intervals for flexible calendars are allocated on a weekly basis.
Currently, the required weekly hours (40h) are distributed across the
first five days of the week without verifying if any of those days are
public holidays. Consequently, if a holiday falls on the 6th or 7th day
of the week, it is ignored by the allocation logic, leading to an incorrect
duration calculation.


reference: [attendance_intervals_batch](https://github.com/odoo/odoo/blob/403866e4b426107d2e869c052cd1a7f16f9a3173/addons/resource/models/resource_calendar.py#L393-L447)


Solution:
---------
Modify the allocation logic to identify public holidays within the week before
distributing hours. Prioritize generating attendance intervals for these
holidays to ensure they are subtracted correctly from the leave duration,
regardless of their position in the week.


opw-5387651

Processing a buy-receive-bill process in a foreign currency and with
an auto-standard product will lead to an incorrect valuation

To reproduce the issue:
(Company in USD)
1. Enable EUR and define the rates as followed:
   - Yesterday: 2
   - Today: 2.5
2. Create a product category:
   - Method: Standard
   - Valuation: Automated
3. Create a product P in that category
   - Cost: 10 USD
4. [Yesterday] Confirm a PO in EUR with 1 x P
5. [Yesterday] Receive it
6. Bill

Error: the stock valuation has two entries: one with 10 USD debit, the
receipt. Another one with 2 USD credit, the currency exchange rate
difference. The second one is a mistake, in a standard configuration,
the stock valuation should be impacted by nothing but the cost defined
on the product form.

Since [1], in some conditions the method `_get_exchange_account`
returns the stock valuation account. This is what happens here, but
it's a mistake since in the above case, we should stick with the
classic account (i.e. the `super` call). The conditions must be more
strict.

[1] https://github.com/odoo/odoo/commit/bae7feefcb08db7329d52bc36517dfd73f3347a7

OPW-5380665

**Steps to reproduce:**
- Install Calendar and Marketing Automation apps
- Go to Calendar
- Add an event with multiple attendees
- Go to Marketing Automation
- Create the marketing automation campaign
- Select `Calendar Event` as target
- Filter to only get your event
- Add an activity with a template
- Launch a test or start the campaign
- Mail is only sent to the owner of the event, not all the participants

Fixed in 19.0 as the attendees also receive the mail

Could also be reproduced with a more useful flow using appointment:
- Add appointment type
- Create meeting on it with a name, attendees, and status set to checked-in
- Create a mail automation campaign for Calendar Event
- Filter on [("appointment_status", "=", "attended")]

**Issue:**
Goal was to set a feedback mail which triggers after a calendar meeting was done. But the recipients are set using the `partner_id` of the record in: 
`default_recipients = RecordsModel.browse(res_ids)._message_get_default_recipients()`

**Fix:**
Override `_message_get_default_recipients` to get the `partner_ids` of all the attendees.

opw-5266543

Whenever an error occurs during the ZATCA onboarding steps—such as
providing a company name that exceeds 127 bytes in binary representation
(for example, 64 Arabic characters without whitespace result in exactly
127 bytes; see refs [1] and [2])—the system returns a traceback to the
user instead of a clear and user-friendly error message.

Error:
`TypeError: argument should be a bytes-like object or ASCII string, not 'NoneType'

This is due to the check-in `_l10n_sa_request_production_csid` for an 'error'
key, not present in the response when an OTP is invalid because in these cases,
the `_l10n_sa_call_api` returns the response_data directly.

This fix improves the behaviour by displaying a user-friendly alert message
with the error returned by ZATCA, instead of a traceback.

This ensures a better experience and compliance with CCSID onboarding flows.

[1]: https://zatca1.discourse.group/t/organization-name-is-too-long-issue-csr/7571
[2]: https://zatca1.discourse.group/t/organisation-name-with-restriction-of-64-characters/960

sentry-7169834710

When the user connect with Stripe in the payment provider and an API request takes longer than 60 seconds then a ReadTimeout error will occur.

Line 1: https://github.com/odoo/odoo/blob/29a40a30f3bf7a4a3a205e54fb84e569691d961f/addons/payment_stripe/models/payment_provider.py#L413-L418

Traceback on sentry:
```
TimeoutError: The read operation timed out
  File "urllib3/connectionpool.py", line 445, in _make_request
    six.raise_from(e, None)
  File "<string>", line 3, in raise_from
    # Permission is hereby granted, free of charge, to any person obtaining a copy
  File "urllib3/connectionpool.py", line 440, in _make_request
    httplib_response = conn.getresponse()
  File "http/client.py", line 1375, in getresponse
    response.begin()
  File "http/client.py", line 318, in begin
    version, status, reason = self._read_status()
  File "http/client.py", line 279, in _read_status
    line = str(self.fp.readline(_MAXLINE + 1), "iso-8859-1")
  File "socket.py", line 705, in readinto
    return self._sock.recv_into(b)
  File "ssl.py", line 1274, in recv_into
    return self.read(nbytes, buffer)
  File "ssl.py", line 1130, in read
    return self._sslobj.read(len, buffer)
ReadTimeoutError: HTTPSConnectionPool(host='stripe.api.odoo.com', port=443): Read timed out. (read timeout=60)
  File "requests/adapters.py", line 439, in send
    resp = conn.urlopen(
  File "urllib3/connectionpool.py", line 755, in urlopen
    retries = retries.increment(
  File "urllib3/util/retry.py", line 532, in increment
    raise six.reraise(type(error), error, _stacktrace)
  File "six.py", line 719, in reraise
    raise value
  File "urllib3/connectionpool.py", line 699, in urlopen
    httplib_response = self._make_request(
  File "urllib3/connectionpool.py", line 447, in _make_request
    self._raise_timeout(err=e, url=url, timeout_value=read_timeout)
  File "urllib3/connectionpool.py", line 336, in _raise_timeout
    raise ReadTimeoutError(
ReadTimeout: HTTPSConnectionPool(host='stripe.api.odoo.com', port=443): Read timed out. (read timeout=60)
  File "odoo/http.py", line 2134, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1710, in _serve_db
    return service_model.retrying(self._serve_ir_http, self.env)
  File "odoo/service/model.py", line 133, in retrying
    result = func()
  File "odoo/http.py", line 1737, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 1938, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 191, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 717, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 34, in call_button
    action = self._call_kw(model, method, args, kwargs)
  File "addons/web/controllers/dataset.py", line 26, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 461, in call_kw
    result = _call_kw_multi(method, model, args, kwargs)
  File "odoo/api.py", line 448, in _call_kw_multi
    result = method(recs, *args, **kwargs)
  File "addons/sale/wizard/payment_provider_onboarding_wizard.py", line 31, in add_payment_methods
    return super().add_payment_methods()
  File "addons/payment/wizards/payment_onboarding_wizard.py", line 141, in add_payment_methods
    return self._start_stripe_onboarding()
  File "addons/sale/wizard/payment_provider_onboarding_wizard.py", line 36, in _start_stripe_onboarding
    return self.env.company._run_payment_onboarding_step(menu_id)
  File "addons/payment/models/res_company.py", line 51, in _run_payment_onboarding_step
    return stripe_provider.action_stripe_connect_account(menu_id=menu_id)
  File "home/odoo/src/custom/trial/saas_payment_stripe/models/payment_provider.py", line 87, in action_stripe_connect_account
    return super().action_stripe_connect_account(menu_id)
  File "addons/payment_stripe/models/payment_provider.py", line 152, in action_stripe_connect_account
    connected_account = self._stripe_fetch_or_create_connected_account()
  File "home/odoo/src/custom/trial/saas_payment_stripe/models/payment_provider.py", line 184, in _stripe_fetch_or_create_connected_account
    connected_account = super()._stripe_fetch_or_create_connected_account()
  File "addons/payment_stripe/models/payment_provider.py", line 326, in _stripe_fetch_or_create_connected_account
    return self._stripe_make_proxy_request(
  File "addons/payment_stripe/models/payment_provider.py", line 414, in _stripe_make_proxy_request
    response = requests.post(url=url, json=proxy_payload, timeout=60)
  File "requests/api.py", line 119, in post
    return request('post', url, data=data, json=json, **kwargs)
  File "requests/api.py", line 61, in request
    return session.request(method=method, url=url, **kwargs)
  File "requests/sessions.py", line 544, in request
    resp = self.send(prep, **send_kwargs)
  File "requests/sessions.py", line 657, in send
    r = adapter.send(request, **kwargs)
  File "requests/adapters.py", line 529, in send
    raise ReadTimeout(e, request=request)

```

To handle this situation, the code has been updated to ensure that if the system takes more than 60 seconds to connect with Stripe then raises a logger warning.

sentry-4506249274

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

Currently, raise an error message in the report editor when trying to edit any reports in the studio mode.

error message: too many values to unpack (expected 2))

When we modify a report, the system tries to make a copy of it. To make this copy, the system needs to provide certain details like the name, mode key etc . At that time system tries to assign multiple values instead of two at this point [1] because the 'key' passed to do a copy of the report is [2] split by '.' as we see in [1] which leads to multiple values instead of two.

link [1]:  https://github.com/odoo/odoo/blob/1648ee1abff1ae12b3933baa85a2e048fa2eb557/odoo/addons/base/models/ir_ui_view.py#L102

link [2]:
https://github.com/odoo/enterprise/blob/34a042bb196273c34cd163f4c43bbd858664b7dc/web_studio/controllers/report.py#L337

To resolve the issue, Add limiting into split, To ensure that there are only two elements in the resulting list, which can unpacked into two (first is module, second is view_id) variables to prevent error.

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

Currently, the  error is generated when the client is trying to modify the view of an existing report through Web Studio.

Steps to reproduce:

- Install the 'web_studio' module and any other module that has report options available for example here we are using the 'account' module.
- Open 'Studio' in Invoicing and  (Turn on the debugger mode)
- Then go to 'Reports' and open any existing report.
- Click on 'More' option and then click on the '</>Qweb Views' button.
- Open the view and remove everything except the first and the last line, Save it now and go back to the report you modified the error will be generated.

```IndexError: list index out of range```

To resolve the issue, we will add a try-except block at [1] to handle errors. This will ensure that if an error occurs when accessing an edited report, it will raise a user error message and this error message will be seen in the report editor.

link [1]: https://github.com/odoo/enterprise/blob/6c538b5ba63be936120f38c90445dfbb2e65a625/web_studio/controllers/report.py#L583-L584

sentry-4650493111

This PR is a cherry-pick of: https://github.com/odoo/odoo/pull/236323

When a pre-filter condition of an automation flushes fields, we must ensure that their recomputation is still scheduled afterwards For example, if a rule pre-filters on field B (which depends on A), computing A should not clear the compute flag of B

### Issue:
In some automation rules, computed fields must be processed in a specific order (e.g., `effective_hours` -> `remaining_hours`)
However, if `remaining_hours` is referenced in the automation `Before Update Domain`, its compute flag may be incorrectly cleared, preventing the proper recomputation chain

This results in inconsistent behavior, such as delays in activities being created when timesheets exceed allocated time

### Cause:
The automation engine flushes fields referenced in the `Before Update Domain`, but does not restore their compute flags afterward Thus dependent fields are not recomputed as expected

### Steps to reproduce:
1. Enable Debug Mode
2. Create an Automation Rule
-- Name: Time Exceeded
-- Model: Task
-- Trigger: On Save
-- Before Update Domain: [("remaining_hours", ">=", 0)]
-- Apply on: [("remaining_hours", "<", 0)]
4. Create a Project with Timesheets
5. Create a Task inside the Project
6. Set Allocated Time to 10h
7. Use the Start button to record 11h (No activity appears in chatter)
8. Do the same again (Activity appears only after the second exceed) Before the fix, there is always a delay because the recomputation chain is broken

### Tickets:
18.0: opw-4409744
17.0: opw-5237430

**Steps to reproduce:**
* Install the **Repair** module with demo data.
* From Setting -> enable 'Discounts' and 'Pricelists'
* From the home screen, search for Pricelist and open it.
* Open the default USD pricelist and go to Configuration →
`Show public price & discount to the customer`
* Open the *Repair* app.
* Create a **Repair Order with parts**.
* Click **Create Quotation** button from the repair order.
* In the quotation,  order line and set a **discount**.
* Return to the repair order using the **Repairs** smart button.
* Confirm the repair order, then **Start repair** and **End repair**  order.

**Observed behavior:**
* The discount added on the quotation line disappears from the linked sale order line.

**Cause:**
* The `discount` field on `sale.order.line` is computed by `_compute_discount`,
  which `depends` on `product_id`, `product_uom`, and `product_uom_qty`.
  When `product_uom_qty` is written during `action_repair_done`, the
  compute method is triggered and the `discount` is recalculated.
https://github.com/odoo/odoo/blob/49169c4c4fec57d78cd82c4c9366de9d69540e6a/addons/repair/models/repair.py#L457

**Fix:**
* Remove the for loop that calls `write()` on the sale order lines, as it
  is functionally incorrect and causes the discount to be reset.

---
opw-5352567

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