# Introduction
This PR fixes broken mention links linked to the fact that we replace strings
without paying attention to the fact that some strings may contain others
that we want to replace later. This affects both id's and names of records.
See commit messages for more details.

# How to reproduce
- Create Contact A and then Contact B and either :
   - Contact B's id need to contain Contact A's id (e.g. Contact B id = 12; Contact A id = 1)
   - Contact B's name need to contain Contact A's name (e.g. Contact B name = ABC; Contact A name = AB)
- In a chatter create a message mentionning first Contact B and then Contact A
> Depending on the version, you might need to reload the page here

- Edit the message and save

# The issue
We see a broken mention in the chatter

# Cause
When saving an edited message, we give the raw body of the message (without the mention links) and the mentionend partners to `generateMentionsLinks` : https://github.com/odoo/odoo/blob/f9f605b1783d252d5e005bec50a2a72dd4ae0e13/addons/mail/static/src/utils/common/format.js#L152

This method's purpose is to replace the text links ("@Contact A") with actual html links. It does so by enumerating each partner given as an argument and replace the text mention with a placeholder :
https://github.com/odoo/odoo/blob/f9f605b1783d252d5e005bec50a2a72dd4ae0e13/addons/mail/static/src/utils/common/format.js#L158

It will then replace the placeholders with actual links : https://github.com/odoo/odoo/blob/f9f605b1783d252d5e005bec50a2a72dd4ae0e13/addons/mail/static/src/utils/common/format.js#L208-L218

The issue is that in both of those steps, we can try to replace a string that is contained
in another string we want to replace. 

For exemple : 
"string123 some text string12"
If we try to replace "string12" first, then we will select the wrong string : 
"[string12]3 some text string12".

opw-6313748

Forward-Port-Of: odoo/odoo#283817
Forward-Port-Of: odoo/odoo#272549

## Steps to reproduce:
	- Install project_purchase_stock and sale_project_stock
	- Create a RFQ and link it to a project
	- Confirm the RFQ
	- Check the linked stock picking
	- Notice the project didn't auto-populate from the PO to the stock picking

## Cause:
During preparing the picking creation values. In the override chain for `_get_new_picking_values` we have two modules that adds `project_id` value

https://github.com/odoo/odoo/blob/658018684d781fef8bf77a77f1e050d1eb16937c/addons/sale_project_stock/models/stock_move.py#L60-L64

https://github.com/odoo/odoo/blob/658018684d781fef8bf77a77f1e050d1eb16937c/addons/project_purchase_stock/models/stock_move.py#L9-L13

And since the one in sale_project_stock is called first so when we are returning the values it will overwrite the project_id value that has been added in project_purchase_stock

## Fix:
Make sure that there are not value for project_id
before setting another value to avoid overwriting the value

the fix is a backport of part of this commit https://github.com/odoo/odoo/commit/b1caeacc3fa73b71de7254f1aa8334154f6db8cc

opw-6459561

Forward-Port-Of: odoo/odoo#282777

The aim of this commit is to allow customer to make their batch payment
without facing a Traceback.

Context:
odoo/enterprise@35f5341b9b44cc16eaea311295a064189dd802cb introduced bug
during a badly handled forward port.
The method was removed in saas-18.3 in favor of a function. The forward-port
was half handled and now surfaces to Odoo's own production.

Generating a batch payment could generates the following Traceback:
```py
  File "/home/odoo/src/enterprise/saas-19.3/account_iso20022/models/account_journal_sepa_ct.py", line 69, in _get_PstlAdr
    return super()._get_PstlAdr(partner_id, payment_method_code)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/src/enterprise/saas-19.3/account_iso20022/models/account_journal.py", line 501, in _get_PstlAdr
    CtrySubDvsn.text = self._sepa_sanitize_communication(partner_address['state'][:35])
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'account.journal' object has no attribute '_sepa_sanitize_communication'
```

Task-id: None (internal issue)

Forward-Port-Of: odoo/enterprise#129084
Forward-Port-Of: odoo/enterprise#129006

**Steps to reproduce:**
- Make a rounding method, Nearest and 0.05 of rounding
- Make a product that costs $4.99, don't set a tax
- Go to the PoS
- Order the product
- Before paying click the +10 button, then pay
- The rounding line is not present on the ticket

**Why the fix:**

When making a normal rounded purchase, by just clicking the "Cash" button, the rounding line will be displayed.

This is because we do not try to apply the rounding if the rounding of the remaining is not equal to zero.
https://github.com/odoo/odoo/blob/995629db3231de944710751c3184bf1b8b1355c7/addons/point_of_sale/static/src/app/models/accounting/pos_order_accounting.js#L118-L123

When we try to over pay, the remaining will be negative by the amount we overpay, so the amount will be set to zero, and the rounding will not be set.

We now take the amount we overpay into account, and deduct it from the amount we paid to then correctly compute the remaining amount without having to deal with the amount overpaid.

Some tests were not taking the rounding as it was not working correctly, so it has now been changed now that it works as it should.

opw-6025807

Forward-Port-Of: odoo/odoo#283413
Forward-Port-Of: odoo/odoo#256117

[Adoption of Owl v3.0.0-alpha.42] in Odoo codebase introduced timing
differences when mounting a new App (sub-)root. This timing difference could
cause a crash when mounting an embedded component in a html field, if the main
App switched view away from the field where embedded components were waiting for
their root to prepare, the root host wouldn't be in the DOM anymore, but the
code would still try to mount these components.

To avoid the issue, this commit makes use of `onBeforeComplete` to abort a
pending mount if the owner instance (Component, editor plugin, ...) was
destroyed before the mount could be initiated. This is the best strategy to
silently ignore crashes caused by premature destruction of an ancestor while
still keeping errors thrown when the host was removed from the DOM for other
reasons that may need investigation. Aborting when the host is disconnected is
the best strategy to avoid the crash entirely, but then we might miss those
other reasons.

[Adoption of Owl v3.0.0-alpha.42]: https://github.com/odoo/odoo/commit/acb95b28ab807b37ee86b381b555e38fae36ae93

runbot-944116

Steps to reproduce
---
1. Install Sales (with Margins) and Project, and open a billable project linked to a sale order.
2. From the project's Expenses view, create an expense paid by the Company and post it.
3. Open the project's Actual Margins: the expense shows under Other Revenues as a positive amount.

Issue
---
Creating an expense from a project's Expenses view keeps `project_id` in the context until its journal entry is built. For a company-paid expense that entry is a payment, and `AccountMoveLine._compute_analytic_distribution` puts the project's analytic distribution on every line that is not receivable or payable, which also covers the Outstanding Payments liquidity line. An analytic amount is the opposite of the move line balance, so the negative liquidity balance becomes a positive analytic line, classified as Other Revenues, on top of the real cost already booked on the expense account.

The receivable/payable filter from b6200026ecf1 narrowed the override introduced in ac1995ad6ddf but ignored the liquidity counterpart of a payment; since only profit and loss lines make up a project margin, restricting the distribution to `income` and `expense` accounts keeps the settlement line out of the report.

https://github.com/odoo/odoo/blob/f037dead17eb6a74d1ea9c56b0861b285be17516/addons/sale_project/models/account_move_line.py#L10-L19

opw-6326551

Forward-Port-Of: odoo/odoo#283938
Forward-Port-Of: odoo/odoo#273273

### Steps to reproduce:

- Enable Multi-Steps Routes, subcontracting and unarchive the MTO route
- Create 3 products: Final Product (FP), Subcontracted Component (SB), Component (COMP) and put SB in MTO
- Create a BOM for FP: 1 x SB
- Create a subcontracted BOM for SB: 1 x COMP
- Create and confirm an MO for 1 unit of FP
> This generates a subcontracted MO for 1 unit of SB
- Confrim the subcontracted PO and go back to the MO of FP
#### > The component move forecast appears "Available" even if the SB unit is neither received nor 'pre-reserved' (the quantity of the move raw is still 0).

### Cause of the issue:

The `forecast_widget` displays an available status in case the demand of the move is expected to be fulfilled and there is no `forecastExpectedDate`:
https://github.com/odoo/odoo/blob/a46cdcd9d0b575eb668ed738565637f346bbdf7b/addons/stock/static/src/widgets/forecast_widget.xml#L1-L19 https://github.com/odoo/odoo/blob/4fbd88ad3ac2d92b47b024b96f1c40ed4b3f97e3/addons/stock/static/src/widgets/forecast_widget.js#L15-L26 Now, the issue is that this `forecastExpectedDate` is currently unreliable in this use case as the `forecast_expected_date` of the SB component move is incorrectly computed to be False rather than matching its subcontracted receipt counter part. To be more precise, the `forecast_expected_date` is computed based on the report lines: https://github.com/odoo/odoo/blob/8b8b99e371fcf214b9c55fb2fbfca20f2ee66f53/addons/stock/models/stock_move.py#L579-L581 https://github.com/odoo/odoo/blob/8b8b99e371fcf214b9c55fb2fbfca20f2ee66f53/addons/stock/models/stock_move.py#L2701 The component move is an out move of SB from Stock to Production and is linked to the finished subcontracted move of SB from Production to Subcontracting. In particular, this finished subcontracted move (which is assigned) contributes to the 'reserved' out qties on the get go and leads to an already reserved out quantity of 1.0 even thought the move is purely external and linked to the subcontractor process: https://github.com/odoo/odoo/blob/ef89bc530ffae93a553003559ca9078b7a9d0653/addons/stock/report/stock_forecasted.py#L241-L268
In turn, the `demand_out` matched its `reserved_out` (even thought this reserved_out should be 0) so that no `in_transit` move is provided to provide an `expected_date`:
https://github.com/odoo/odoo/blob/ef89bc530ffae93a553003559ca9078b7a9d0653/addons/stock/report/stock_forecasted.py#L426-L435

opw-6445209

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

Forward-Port-Of: odoo/odoo#283177

Before this commit:
---

When [`absence_management`](https://github.com/odoo/odoo/blob/b3444e4bd421a30229b0dc7c8d5eb6c78b8b51ed/addons/hr_attendance/models/res_company.py#L42) is enabled, a [scheduled action](https://github.com/odoo/odoo/blob/b3444e4bd421a30229b0dc7c8d5eb6c78b8b51ed/addons/hr_attendance/models/hr_attendance.py#L645) automatically creates an attendance record at [**12:00:00 AM**](https://github.com/odoo/odoo/blob/b3444e4bd421a30229b0dc7c8d5eb6c78b8b51ed/addons/hr_attendance/models/hr_attendance.py#L649) to mark negative extra hours for employees with missing attendance.

<img width="1147" height="474" alt="image" src="https://github.com/user-attachments/assets/833a4387-bc20-4bb7-817d-9ebe9afa7d71" />


If an employee later creates a leave covering this autogenerated attendance, the extra hours should be reset to `0`. However, this does not happen.

#### Video demonstration:
https://drive.google.com/file/d/1DTNQuQ3uV5nOUVMBazCDo0hBZbKJZUIW/view

This happens because the [domain](https://github.com/odoo/odoo/blob/b3444e4bd421a30229b0dc7c8d5eb6c78b8b51ed/addons/hr_holidays_attendance/models/resource_calendar_leaves.py#L8) used to fetch attendances for [`_update_overtime`](https://github.com/odoo/odoo/blob/b3444e4bd421a30229b0dc7c8d5eb6c78b8b51ed/addons/hr_holidays_attendance/models/resource_calendar_leaves.py#L34) compares the attendance `check_in` and `check_out` datetimes with the leave `date_from` and `date_to` datetimes.

The leave datetimes are aligned with the employee's working schedule. For example, if the working hours are **8:00 AM–5:00 PM**, the leave is stored from `{date, 8:00 AM}` to `{date, 5:00 PM}`. In contrast, the scheduled action creates the autogenerated absence attendance at **12:00:00 AM** (in the user's timezone). Since this attendance falls outside the leave datetime range, it is excluded from the domain, and `_update_overtime` is never called for it.

After this fix:
---

Instead of building the domain using the leave datetime range, the domain is built using the leave date range. This ensures that all attendances for the affected dates, including autogenerated absence attendances created at midnight, are included and their extra hours are updated correctly.

OPW: 6385811




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

Forward-Port-Of: odoo/odoo#281123

### Issue before this commit:
When using the "Reverse and Create Invoice" feature on a posted invoice with a foreign currency and Cash Basis enabled, the expected Exchange Difference and Cash Basis tax entries are not generated upon the automatic reconciliation. The credit note is successfully created and reconciled with the original invoice, but the P&L exchange difference and the cash basis transition lines are completely missing. Currently, the only workaround is to manually reset the generated credit note to draft and re-post it, which forces the system to correctly calculate the currency rate differences and generate the missing entries.

### Steps to reproduce the issue:
1. Download Accounting
2. Go to Settings > Cash basis. Tick it and set as 'Base Tax Received Account' an account like 201000 Current Liabilities
3. Go to Chart of Accounts > search your account (ex. 201000 Current Liabilities) and be sure the flag of 'Allow Reconciliation' is on
4. Go to Taxes > 15% sales > set 'Tax Exigibility' as Based on Payment and 'Cash Basis Transition Account' always as 201000 Current Liabilities
5. Go to Currencies and set a new currency like MXN inserting tax rates as:
	1. 1 july 2026: 20$
	2. 15 july 2026: 15$
6. Create a new invoice with price 100 and 15% tax, set MXN as currency for the journal, set the date as 1 july and confirm it
7. Click on 'Credit Note', then 'Reverse and Create Invoice' and confirm it
8. go back to the invoice and see that after the total amount there is a new line 'Reversed on...'
9. After that line there should also be the line with the Exchange Difference since the tax rates for MXN currency were different at the moment of the invoice and at the moment of the credit note. This is only created by resetting to draft the credit note and confirm it again.

### Cause of the issue:
In the account.move.reversal wizard, when is_modify = True (Reverse and Create), the system triggers _reverse_moves with cancel=True. At the end of the _reverse_moves method, the newly created reverse moves are automatically posted and reconciled. However, this automatic posting is executed with move_reverse_cancel=True injected into the context: reverse_moves.with_context(move_reverse_cancel=cancel)._post(soft=False). When the reconciliation engine (_reconcile_plan_with_sync and _create_exchange_difference_moves) detects this specific context key, it intentionally bypasses the creation of both the exchange difference P&L moves and the cash basis entries, treating the reversal as a pure administrative cancellation rather than a financial operation with currency fluctuations.

### Reason to introduce the fix:
To ensure financial accuracy and compliance, especially when cash basis and multi-currency are involved, a reversal on a different date must reflect the actual exchange rate fluctuations and properly trigger cash basis rules. By removing the move_reverse_cancel context injection during the automatic posting of the reverse moves, we allow the native reconciliation engine to evaluate the newly computed balance (based on the credit note's date) against the original invoice. This ensures that exchange differences and cash basis journal entries are automatically and accurately generated on the first attempt.

opw-6399867

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

Forward-Port-Of: odoo/odoo#283306
Forward-Port-Of: odoo/odoo#281498

Steps to reproduce:
===================
1. Add a video (e.g. a YouTube URL) to a product from the Sales app.
2. Open the product page on the website.
3. Slide the carousel to the video.

=> The video preview cover is blurry.

Root cause:
===========
The product images are rendered in a carousel (the shop_product_carousel template in ) where only the first slide  gets the "active" class; https://github.com/odoo/odoo/blob/af1b3ee2e7ac56a35bff5e030c3a831c27dbcf24/addons/website_sale/views/templates.xml#L3224-L3226 every other slide is "display: none".
A product video is rendered as a live <iframe> inside its slide, so when the video is not the first media its iframe loads while its container has no  dimensions (0x0). The embedded player then initializes as a small mobile player and loads a low resolution cover thumbnail (120x90), which looks blurry once the slide is shown at full size. Reloading only the iframe while the slide is visible fixes it, a full page reload does not.

Fix:
====
Defer loading the video iframes located on hidden slides their src is moved to a data-src attribute on start and restored once the slide becomes visible. The player then initializes at full size and loads a high resolution cover.

opw-6349394


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

Forward-Port-Of: odoo/odoo#282508
Forward-Port-Of: odoo/odoo#274002

**Setup**

* Increase the debounce time of `debouncedSynchronizeLocalDataInIndexedDB` to **5 seconds** to reproduce the issue deterministically.
* Configure a restaurant with **Self Ordering** enabled (`QR Menu + Ordering`).
* Configure **Mollie** as the **only** online payment method.

**Reproduction**

1. Place a **takeout** order through the mobile menu.
2. Select a pickup time, enter the required customer information (including a mobile number), and proceed to the payment page.
3. Verify from the backend that the draft order contains the expected data (customer/partner and `preset_time`).
4. Press the browser **Back** button to return from the payment page.
5. Check the draft order in the backend again.
[video](https://drive.google.com/file/d/1kNWpYuo79mYMV3eMelwJ5IDFeWUc7zsD/view)


**Observed result**

* The draft order loses its previously synced information. In particular, the **partner/customer** data (and other synced fields such as `preset_time`) are removed.

**Expected result**

* Returning from the payment page should not modify the draft order. All previously synced data should remain intact.

**Cause**
- When there's only a single payment method, it's [auto-selected](https://github.com/odoo/odoo/blob/161715c850496d3683baa5d1600380470d0b5ff5/addons/pos_self_order/static/src/app/pages/payment_page/payment_page.js#L21-L22) and `checkAndOpenPaymentPage` immediately opens the payment page via[ window.open()](https://github.com/odoo/odoo/blob/161715c850496d3683baa5d1600380470d0b5ff5/addons/pos_online_payment_self_order/static/src/app/pages/payment_page/payment_page.js#L35).
- The order's local data is saved to IndexedDB on a 300ms debounce. If the redirect fires before that debounce completes, the save is cancelled, leaving IndexedDB out of sync with the in-memory order

**Fix**
  - Before opening the payment URL, explicitly flush the order to IndexedDB using
  the `synchronizeLocalDataInIndexedDB`, ensuring the local data is persisted
  before the page navigates away.


opw-6231478

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

Forward-Port-Of: odoo/odoo#283800
Forward-Port-Of: odoo/odoo#272724

*=account, hr_timesheet, loyalty, mrp_subcontracting, project, purchase, sale, website_crm_partner_assign

Steps to reproduce:
1. install sale
2. Create and confirm a sale order for a portal user
3. Login as a portal user
4. Open sale orders

Issue:
- Breadcrumbs are not visible beside the title.

Cause:
- After this commit https://github.com/odoo/odoo/commit/bba2fc505f5d0b4770eacc6877155b1aeda6d772
Variables are passed as attributes directly on the element, but breadcrumbs_searchbar
was passed to portal_layout, but the nested portal_searchbar no longer received it.
As a result, portal list pages rendered their title instead of the breadcrumb home link.

Solution:
- Pass breadcrumbs_searchbar directly to portal_searchbar

Alternative:
- An alternative would be to propagate t-call parameters to slot content
in QWeb or changes the condition for breadcrumbs visibility

related enterprise pr: https://github.com/odoo/enterprise/pull/118352

opw-6232899

Forward-Port-Of: odoo/odoo#266020

Steps to reproduce:
--------------------------------------------
1. Install Attendance module.
2. Enable `Device & Location Tracking` & `Attendance from Backend` in settings.
3. Block location access from the browser for this site (Site settings)
4. Try to checkIn/checkOut from the Dot in the systray
5. We'll have one confirmation pop-up asking to Proceed Anyway OR Discard

Observation:
--------------------------------------------
On clicking the discard button, Nothing happens.

Issue:
--------------------------------------------
In `confirmChecking()`, the `cancel` callback was defined as an arrow function using an expression body. In JavaScript, an assignment expression returns the assigned value. Since `this._attendanceInProgress` is set to `false`, the callback implicitly returns `false`.

`ConfirmationDialog.execButton()` treats a `false` return value as a signal to keep the dialog open (used intentionally to block closing on validation failure) This caused the dialog to never call `this.props.close()`, leaving it permanently open when Discard was clicked.

https://github.com/odoo/odoo/blob/5e84fdd99e34836a15cadc4fdf4b6bc449727e58/addons/web/static/src/core/confirmation_dialog/confirmation_dialog.js#L75-L89

Solution:
--------------------------------------------
Change the `cancel` callback from an expression body to a block body, A block body arrow function returns `undefined` by default. This ensures `execButton` does not interpret the return value as a 'keep dialog open' signal, and correctly calls `this.props.close()` to dismiss the dialog.

opw-6462439

Forward-Port-Of: odoo/odoo#281702

Steps to produce:
---
- Install `sale_management` and `sale_loyalty` module without demo.
- From sales > products > discounts & loyalty, create new loyalty card program and save.
- Now create new product of 100$.
- Create a user which have sales rights as `user: own documents only`.
- With that user, create new sale order with product and confirm.
- Try to cancel the order.

Issue:
---
- It shows the access error: 
```py
You are not allowed to delete 'Sale Order Coupon Points - Keeps track of how a
 sale order impacts a coupon' (sale.order.coupon.points) records.

This operation is allowed for the following groups:
	- Sales/Administrator

Contact your administrator to request access if necessary.
```

Root cause:
---
- Users with the `Sales: Own Documents Only` access right only have read permissions ([1]). When they cancel a Sales Order, the `_action_cancel` method attempts to clean up the temporary pending points allocated to the order by calling `self.coupon_point_ids.unlink()`. Because this call is executed without elevated privileges, the system blocks the deletion and raises an Access Error

Solution:
---
- Added `.sudo()` to the `unlink()` call for `coupon_point_ids` in the `_action_cancel` method. This ensures the pending point records are cleaned up with the necessary elevated privileges.

[1]https://github.com/odoo/odoo/blob/23af2b443735c6d3a2f64e44f9ea5da45638b052/addons/sale_loyalty/security/ir.model.access.csv#L16

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

Forward-Port-Of: odoo/odoo#284122
Forward-Port-Of: odoo/odoo#281477

Before this commit, it was impossible to use budget on the Moroccan P&L, for the following reasons:

- The feature was designed for one-column reports. MA's P&L uses 3, one of which is the total of the two others.

=> We remove that requirement, and make sure to always select the 'balance' column as the reference for the budget comparison.

- When trying to input a budget amount in the report, the amount disappeared entirely.

    => This was because the total column of report was not using 'balance' as its expression label. We fix that by rewriting the expression labels of that report.

The fact we hardcode the use of 'balance' is arguable. It is however not possible here to rely on some custom handler to change a specific option key that would be used to generate the budget comparison data, since some of those data need to be generated in the get_options, before _custom_options_initializer even gets called. This is the simplest approach, and this case is rare enough for us to deem it acceptable.

opw-6385229

Forward-Port-Of: odoo/enterprise#129003
Forward-Port-Of: odoo/enterprise#128266

**Steps to reproduce:**
- Install Accounting, Sales and l10n_pe_edi
- Switch to a Peruvian company (e.g. PE Company)

- Create a SO:
  * Customer: [a Peruvian customer]
  * Order Lines:
    | Product | Quantity | Unit Price |  Taxes  | 
    | ------- | -------- | ---------- | ------- |
    |   any   |   3.00   |   123.50   | VAT 18% |
    |   any   |   2.00   |  27.544216 |  0% Ina |
    |   any   |   1.00   |  43.490867 |  0% Exo |

- Confirm the SO
- Create a 40% down payment
- Confirm the down payment
- Process it to sent it to Peru UBL 2.1

**Issue:**
The following error message is returned by the OSE:
`3272|La base imponible a nivel de línea difiere de lainformación consignada en el comprobante - Detalle: xxx.xxx.xxx ticket : 20260000000000221633458 error: Error en la Linea Nro. :1. : 3272 (nodo: "cac:TaxSubtotal/cbc:TaxableAmount" valor: "148.20")`

**Cause:**
In the XML, one line has 148.19 for "cbc:LineExtensionAmount", but 148.20 for "cac:TaxSubtotal/cbc:TaxableAmount".
The issue is coming from the fact that "base_amount_currency" is used instead of "total_excluded_currency" for the computation of "cac:TaxSubtotal/cbc:TaxableAmount".

**Issue 2:**
When a tax is impacting the base amount of a following tax, its tax amount is not taken into account in "total_excluded_currency".

opw-6235909

Forward-Port-Of: odoo/enterprise#128881
Forward-Port-Of: odoo/enterprise#122310

Currently, an error occurs when user opens tax returns.

Steps to replicate:
- Install `accountant`.
- Open Accounting > Accounting > Tax Returns.
- Add an `Opening date` and click apply.

Error:
```
Uncaught Promise > Ref is undefined or null
OwlError: Ref is undefined or null
    Error: Ref is undefined or null
        at createRef (http://localhost:8069/web/assets/1f0e4b3/web.assets_web.min.js:1099:47)
        at AccountReturnKanbanRenderer.template_account_reports_account_return_kanban_renderer (eval at compile (http://localhost:8069/web/assets/1f0e4b3/web.assets_web.min.js:1503:228), <anonymous>:13:16)
```

Cause:
- Error occurs after a recent [PR].
- In OWL 3, the `t-ref` directive expects a `signal`, whereas here it is provided with a string `root`, causing the error.
- OWL 2 allowed `t-ref` to be used with a string, so a new `t-custom-ref` directive was introduced to retain support for string-based references to DOM elements.

Solution:
- Replaced `t-ref` to `t-custom-ref`.
- Please refer to [1] and [2].

[PR]: https://github.com/odoo/enterprise/pull/128391

[1]: https://github.com/odoo/odoo/blob/a460aabc659af8ff6282dac77dbaf71fd3ff30f5/addons/web/static/src/owl2/owl3_compatibility_layer.js#L14

[2]: https://github.com/odoo/odoo/pull/246876

No Task ID

* = account_invoice_extract, l10n_nl_reports

Example of steps:
- Install web_studio and `accountant`
- Open the corresponding form view in Studio
- With debug mode toggle "Show invisible Elements" and edit
"Invisible" on the second partner_id field
- Traceback

`normalize()` compares the combined arch without the studio
customization to the one with it, in order to compute the smallest
possible set of xpaths. To do so, it calls `apply_inheritance_specs`
(the low-level function from `odoo.tools.template_inheritance`)
directly on the statically combined arch.

Some models add or duplicate nodes dynamically in `_get_view()`
(Python postprocessing, run after the static view combination). A
studio operation can target such a node, since it is what the user
actually sees and clicks on. But that node has no counterpart in the
purely static combined arch used by `normalize()`, so
`apply_inheritance_specs` raises a ValueError.

`edit_view()` only catches `ValidationError` to fall back to an
un-optimized (but valid) studio arch instead of failing the request.
Since the low-level function raises a plain `ValueError` here, that
fallback never triggers, and the exception is not caught anywhere.

To fix this, we will keep the behavior from version 18.0 and catch the
ValueError raised by `apply_inheritance_specs` in
`normalize_with_keyed_tree` and re-raise it as a ValidationError, like
`ir.ui.view.apply_inheritance_specs` already does elsewhere. This lets
`edit_view()`'s existing fallback handle the case gracefully instead
of crashing.

Additionally, the two models responsible for the dynamically-added nodes
described above are fixed at the source. `account_invoice_extract`'s
duplicated `partner_id` field and `l10n_nl_reports`'s injected
`company_id` field are now marked with `data-used-by`, the same
attribute `_add_missing_fields` already sets in `ir_ui_view.py` for the
fields it adds.
Studio already skip rendering and computing xpaths for any node carrying
this attribute (since https://github.com/odoo/enterprise/pull/92862),
so these nodes are no longer exposed to the user and can no longer
produce a studio operation that `normalize()` is unable to locate.

opw-6332911

Forward-Port-Of: odoo/enterprise#127009
Forward-Port-Of: odoo/enterprise#122829

Problem:
When using horizontal groups in Aged Receivables / Aged Payables reports, the amounts shown in the Older periods are incorrect.

Steps to reproduce:
1. Activate debug mode
2. Go to Accounting > Configuration > Horizontal Groups
3. Add a new horizontal group that results in at least 2 groups
4. Go to Accounting > Reporting > Aged Receivables / Aged Payables
5. Apply the horizontal group created
6. Notice how the amount in the Older period is incorrect, different from before applying the horizontal group. (It may be coincidentally correct, you can check by applying different aging intervals until you find one that shows the issue)

Cause:
The periods were not correctly calculated. The number of periods was calculated based on the number of period columns, without taking into account the number of column groups. When using horizontal groups, period columns are duplicated for each group that exists after applying the horziontal group. This is not considered when calculating the number of periods, which results in calculating too many periods and therefore having incorrect durations for each period.

opw-6374639

Forward-Port-Of: odoo/enterprise#127570

Currently, an error occurs when user deletes all the variants of a product and opens the website raises an error.

Steps to replicate:
- Install `website_sale_renting`, open settings and turn on `Product Variants`.
- Create a new product `test` , give an attribute and 2 values.
- Click on the `Variants` smart button,  select all and delete.
- Publish this produce in website and open shop on website.

Error:
```
ValueError: Expected singleton: product.product()
```

Cause:
- Issue occurs after a recent change (check [PR]) that added a check if product is donation.
- As the user deleted all the variants of the product `test`, when flow reaches here [1] the `self.product_variant_id` is an empty recordset and then the method `_can_be_added_to_current_cart()` calls `_is_donation()` [2] which raises a singleton error [3].

Solution:
- If the product doesnt have any variants (based on previous versions) we return true, while the product will still not be able to be added to the cart by [this] `UserError`.

[PR]: https://github.com/odoo/enterprise/pull/118130

[1]: https://github.com/odoo/enterprise/blob/639d303aefb51ae7d426ff1d83f2aa7e652187e3/website_sale_renting/models/product_template.py#L129

[2]: https://github.com/odoo/enterprise/blob/639d303aefb51ae7d426ff1d83f2aa7e652187e3/website_sale_renting/models/product_product.py#L21

[3]: https://github.com/odoo/odoo/blob/5dc090a2f449dc05284a760cbdd11a94b51e5457/addons/website_sale/models/product_product.py#L306

[this]: https://github.com/odoo/odoo/blob/5dc090a2f449dc05284a760cbdd11a94b51e5457/addons/website_sale/controllers/cart.py#L127-L131

sentry-7635385579