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

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

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

Currently, an error occurs when adding a deadline interval date to a task.

Step to produce:

- Install the `industry_fsm` module and turn on the debugger.
- Go to Settings / Technical / Resource / Resources, open record name 'Mitchell admin' and remove the value of  'Working Time'.
- Go to Project / Tasks / My tasks, Create a task with Deadline intervals, Make sure Assignees is a  'Mitchell admin' as we removed the value of 'Working Time' from it

Traceback On Sentry:

```
ValueError: not enough values to unpack (expected 1, got 0)
  File "odoo/models.py", line 5851, in ensure_one
    _id, = self._ids
ValueError: Expected singleton: resource.calendar()
  File "odoo/http.py", line 2248, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1823, in _serve_db
    return self._transactioning(_serve_ir_http, readonly=ro)
  File "odoo/http.py", line 1843, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 134, in retrying
    result = func()
  File "odoo/http.py", line 1821, in _serve_ir_http
    return self._serve_ir_http(rule, args)
  File "odoo/http.py", line 1828, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2053, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 756, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 38, in call_kw
    return self._call_kw(model, method, args, kwargs)
  File "addons/web/controllers/dataset.py", line 34, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 458, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
  File "addons/web/models/models.py", line 71, in web_save
    self.write(vals)
  File "home/odoo/src/enterprise/saas-17.2/helpdesk_fsm/models/project_task.py", line 45, in write
    res = super().write(vals)
  File "home/odoo/src/enterprise/saas-17.2/industry_fsm/models/project_task.py", line 193, in write
    return super(Task, self_fsm).write(vals)
  File "addons/project_sms/models/project_task.py", line 25, in write
    res = super().write(vals)
  File "home/odoo/src/enterprise/saas-17.2/project_enterprise/models/project_task.py", line 472, in write
    work_intervals = calendar._work_intervals_batch(start, stop, resources=resource)
  File "addons/resource/models/resource_calendar.py", line 434, in _work_intervals_batch
    attendance_intervals = self._attendance_intervals_batch(start_dt, end_dt, resources, tz=tz or self.env.context.get("employee_timezone"))
  File "addons/resource/models/resource_calendar.py", line 273, in _attendance_intervals_batch
    self.ensure_one()
  File "odoo/models.py", line 5854, in ensure_one
    raise ValueError("Expected singleton: %s" % self)

```

An error occurs when the system tries to access the method name '_work_intervals_batch' without a resource calendar record at [1].

link [1]: https://github.com/odoo/enterprise/blob/4a09f71c13f26dd538603c1fdbb34da7bc0d2a97/project_enterprise/models/project_task.py#L470-L472

To resolve this issue, Add a condition that checks if the resource calendar_id is not available, then try to plan tasks for a user that has no calendar.

sentry - 5534568281

Currently, The traceback message is occurring when making a payment with an invalid API.

This error message occurs during the make a payment request with an invalid API key, we need to change the logger error message to a logger warning message at [1] to prevent an error log in a terminal.

Traceback on sentry:

```
gaierror: [Errno -2] Name or service not known
  File "urllib3/connection.py", line 169, in _new_conn
    conn = connection.create_connection(
  File "urllib3/util/connection.py", line 73, in create_connection
    for res in socket.getaddrinfo(host, port, family, socket.SOCK_STREAM):
  File "socket.py", line 955, in getaddrinfo
    for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
NewConnectionError: <urllib3.connection.HTTPSConnection object at 0x7f608ee1e1a0>: Failed to establish a new connection: [Errno -2] Name or service not known
  File "urllib3/connectionpool.py", line 700, in urlopen
    httplib_response = self._make_request(
  File "urllib3/connectionpool.py", line 383, in _make_request
    self._validate_conn(conn)
  File "urllib3/connectionpool.py", line 1017, in _validate_conn
    conn.connect()
  File "urllib3/connection.py", line 353, in connect
    conn = self._new_conn()
  File "urllib3/connection.py", line 181, in _new_conn
    raise NewConnectionError(
MaxRetryError: HTTPSConnectionPool(host='yourneed-checkout-live.adyenpayments.com', port=443): Max retries exceeded with url: /checkout/V70/paymentMethods (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7f608ee1e1a0>: Failed to establish a new connection: [Errno -2] Name or service not known'))
  File "requests/adapters.py", line 439, in send
    resp = conn.urlopen(
  File "urllib3/connectionpool.py", line 756, in urlopen
    retries = retries.increment(
  File "urllib3/util/retry.py", line 574, in increment
    raise MaxRetryError(_pool, url, error or ResponseError(cause))
ConnectionError: HTTPSConnectionPool(host='yourneed-checkout-live.adyenpayments.com', port=443): Max retries exceeded with url: /checkout/V70/paymentMethods (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7f608ee1e1a0>: Failed to establish a new connection: [Errno -2] Name or service not known'))
  File "addons/payment_adyen/models/payment_provider.py", line 121, in _adyen_make_request
    response = requests.request(method, url, json=payload, headers=headers, timeout=60)
  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 516, in send
    raise ConnectionError(e, request=request)
```

link[1]: https://github.com/odoo/odoo/blob/e3ee1f8bd85f3ea7287ab6b78847798190246b5d/addons/payment_adyen/models/payment_provider.py#L124-L127

sentry-4955120723

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

An error occurs when the system tries to retrieve the value of 'blank_if_zero' from 'column_dict', but it is not available at [1]. To handle this issue, we can use the .get() method to obtain the value.

link [1]: https://github.com/odoo/enterprise/blob/adbf9375a07980c8b9b4f621dfaba5ffc99c4162/account_reports/models/account_report.py#L2237


Traceback On Sentry:
```
KeyError: 'blank_if_zero'
  File "odoo/http.py", line 2248, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1823, in _serve_db
    return self._transactioning(_serve_ir_http, readonly=ro)
  File "odoo/http.py", line 1843, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 134, in retrying
    result = func()
  File "odoo/http.py", line 1821, in _serve_ir_http
    return self._serve_ir_http(rule, args)
  File "odoo/http.py", line 1828, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2053, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 756, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 38, in call_kw
    return self._call_kw(model, method, args, kwargs)
  File "addons/web/controllers/dataset.py", line 34, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 458, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
  File "home/odoo/src/enterprise/saas-17.2/account_reports/models/account_report.py", line 2223, in format_column_values
    self._format_column_values(options, lines, force_format=True)
  File "home/odoo/src/enterprise/saas-17.2/account_reports/models/account_report.py", line 2237, in _format_column_values
    elif column_dict['blank_if_zero'] and column_dict['is_zero']:

```

sentry - 5564693263

Changes list view:
- corrected display of Year (before it was formatted as a number)
- added display of # eligible employee and its logic in the backend
- added optional display of both the xml and xls file

Changes form view:
- removed list of eligible employee from the form view, moved in its own line list view (later described)
- refactor of files and payment sections, now consistent with the rest of the UX
- changing dates (either year or month) reset generated files and associated fields, for ux consistency in buttons, file and payment sections

Changes form view header buttons:
- switched logic from static xml to js due to need of handling many different conditions over them, would have otherwise needed to define dozen of static instances for just 3 buttons
- buttons now appear disabled when for the selected dates there is no eligible employee
- buttons now appear as primary if the associated file type still has to be generated, secondary otherwise
- buttons are ordered such that primary ones are displayed first
- button Post Journal Entries removed (along with its related logic)

Changes line list view:
- shown on clicking the smart button in the form view
- added filters for Doctors, Masters, Bachelors certificate levels

Task ID: 5035358

When the ``Default 48 hours/week`` working schedule is deleted and
the ``Payroll: Update data`` cron runs, a traceback is raised.

Steps to reproduce the error:
- Install ``l10n_mx_hr_payroll`` module with demo data
- Switch to ``INNOVACION VALOR Y DESARROLLO SA SA`` company
- Go to Employees > Configuration > Settings > Change Company Working Hours
- Go to Working Schedules > Delete ``Default 48 hours/week`` working schedule
- Run the ``Payroll: Update data`` cron

Traceback:
```py
ValueError: External ID not found in the system: l10n_mx_hr_payroll.resource_calendar_def_48h

ParseError: while parsing /home/odoo/src/enterprise/l10n_mx_hr_payroll/data/hr_payroll_structure_type_data.xml:3, somewhere inside <record id="l10n_mx_employee" model="hr.payroll.structure.type">
        <field name="name">Mexico: Employee</field>
        <field name="default_resource_calendar_id" ref="l10n_mx_hr_payroll.resource_calendar_def_48h"/>
        <field name="country_id" ref="base.mx"/>
    </record>
```

The ``Payroll: Update data`` cron updates payroll data that references the ``Default 48 hours/week`` working schedule.
If the user has deleted this working schedule, the external ID no longer exists, leading to the above traceback.

sentry-7166574553

Forward-Port-Of: odoo/enterprise#103323

## 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, 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, 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

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

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, an exception occurs when a payment session has expired at [1], To handle this issue, raise a validation error instead of raise an exception.

link [1]: https://github.com/odoo/odoo/blob/677f7d0c6085dba4ab9c27a53b4c3fd2d88b190e/addons/payment/controllers/post_processing.py#L48

Traceback On Sentry:

```
Exception: tx_not_found
  File "odoo/http.py", line 2248, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1823, in _serve_db
    return self._transactioning(_serve_ir_http, readonly=ro)
  File "odoo/http.py", line 1843, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 134, in retrying
    result = func()
  File "odoo/http.py", line 1821, in _serve_ir_http
    return self._serve_ir_http(rule, args)
  File "odoo/http.py", line 1828, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2053, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 756, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/payment/controllers/post_processing.py", line 48, in poll_status
    raise Exception('tx_not_found')

```

sentry-4992700034

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

Currently, The  error is occurs whenever user open a 'task' in portal view.

Steps to reproduce

- Install an 'industry_fsm' module.
- Open a portal view.
- Click on 'Tasks' and open an any record form it.

Traceback on sentry:

```
AttributeError: 'project.task' object has no attribute 'display_sign_report_primary'
  File "<2406>", line 1650, in template_2406
  File "<2406>", line 1632, in template_2406_content
  File "<2406>", line 555, in template_2406_t_call_0
  File "<2406>", line 473, in template_2406_t_call_3
  File "<2406>", line 73, in template_2406_t_set_12
QWebException: Error while render the template
AttributeError: 'project.task' object has no attribute 'display_sign_report_primary'
Template: ir.ui.view(2406,)
Path: /t/t/body/div[1]/div/t/t[2]/div/div[2]
Node: <div t-if="task.is_fsm and (task.display_sign_report_primary or task.display_sign_report_secondary)" class="d-grid flex-grow-1 align-items-center mb-2"/>
  File "odoo/http.py", line 2157, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1732, 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 1759, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 1873, in dispatch
    return self.request.registry['ir.http']._dispatch(endpoint)
  File "addons/website/models/ir_http.py", line 235, in _dispatch
    response = super()._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 209, in _dispatch
    result.flatten()
  File "odoo/http.py", line 1248, in flatten
    self.response.append(self.render())
  File "odoo/http.py", line 1240, in render
    return request.env["ir.ui.view"]._render_template(self.template, self.qcontext)
  File "addons/website/models/ir_ui_view.py", line 443, in _render_template
    return super()._render_template(template, values=values)
  File "odoo/addons/base/models/ir_ui_view.py", line 2044, in _render_template
    return self.env['ir.qweb']._render(template, values)
  File "odoo/tools/profiler.py", line 292, in _tracked_method_render
    return method_render(self, template, values, **options)
  File "odoo/addons/base/models/ir_qweb.py", line 593, in _render
    result = ''.join(rendering)
  File "<2406>", line 1656, in template_2406
```

When the user open a 'task' in portal view. There's an issue where the system attempts to access an attribute 'display_sign_report_primary'  from 'project.task' object [1] and the 'project.task' object has no attribute 'display_sign_report_primary'  at that specific point.

Line[1]:https://github.com/odoo/enterprise/blob/ce9122ab0fa8c393e4c37280fcef52377d6fb16f/industry_fsm/views/project_portal_templates.xml#L39

This commit solves this issue by accessing an attribute 'display_sign_report_primary' in the 'industry_fsm_report' module instead of 'industry_fsm' module. This adjustment is necessary as the 'display_sign_report_primary' attribute is not present in the 'industry_fsm'
 module.

sentry-4673429933

Currently, An error is generated when trying to open the 'Profit and Loss' report.

Steps to reproduce:

- Install an 'account_reports' module.
- Navigate to Accounting / Configuration / Management / Accounting Reports, Open 'Profit and Loss', Click on the 'Column' page, and change the value of 'Figure Type' to 'Datetime'
- Open reports Accounting / Reporting / Statement Reports / Profit and Loss.

Stack Trace:

```
AssertionError: null
  File "odoo/http.py", line 2248, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1823, in _serve_db
    return self._transactioning(_serve_ir_http, readonly=ro)
  File "odoo/http.py", line 1843, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 134, in retrying
    result = func()
  File "odoo/http.py", line 1821, in _serve_ir_http
    return self._serve_ir_http(rule, args)
  File "odoo/http.py", line 1828, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2053, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 756, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 38, in call_kw
    return self._call_kw(model, method, args, kwargs)
  File "addons/web/controllers/dataset.py", line 34, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 458, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
  File "home/odoo/src/enterprise/saas-17.2/account_reports/models/account_report.py", line 4441, in get_report_information
    'lines': self._get_lines(options, all_column_groups_expression_totals=all_column_groups_expression_totals, warnings=warnings),
  File "home/odoo/src/enterprise/saas-17.2/account_reports/models/account_report.py", line 2141, in _get_lines
    line_dict = self._get_static_line_dict(options, line, all_column_groups_expression_totals, parent_id=parent_generic_id)
  File "home/odoo/src/enterprise/saas-17.2/account_reports/models/account_report.py", line 2356, in _get_static_line_dict
    {'formula': expression.formula, 'subformula': expression.subformula, 'value': self.format_value(options, column_group_totals[expression]['value'], figure_type)}
  File "home/odoo/src/enterprise/saas-17.2/account_reports/models/account_report.py", line 4834, in format_value
    return self._format_value(options=options, value=value, figure_type=figure_type, format_params=format_params)
  File "home/odoo/src/enterprise/saas-17.2/account_reports/models/account_report.py", line 4870, in _format_value
    return format_date(self.env, value)
  File "odoo/tools/misc.py", line 1327, in format_date
    return babel.dates.format_date(value, format=date_format, locale=locale)
  File "babel/dates.py", line 700, in format_date
    return pattern.apply(date, locale)
  File "babel/dates.py", line 1232, in apply
    return self % DateTimeFormat(datetime, locale)
  File "babel/dates.py", line 1238, in __init__
    assert isinstance(value, (date, datetime, time))

```

The issue occurs when the system tries to format a value into a date at [1] that is not a string.

link [1]: https://github.com/odoo/enterprise/blob/d31f359e543a9413623d4a15aebba54e8d76d023/account_reports/models/account_report.py#L4797

To resolve this issue, Add a try-except block to handle errors that occur during date formatting

Sentry-5646185230

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