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

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

Seven entries of the Mexican chart of accounts template carry a name belonging
to a **different** group, copied from a neighbouring entry. Each record's XML ID
still states the intended name, which is what this restores.

| Code | Field | Before | After |
|---|---|---|---|
| `6` | `name@es` | Gastos generales | Gastos |
| `252.07` | `name@es` | `account_subgroup_hipotecas_por_pagar_a_largo_plazo_nacional` | Hipotecas por pagar a largo plazo nacional |
| `602` | `name`, `name@es` | Cost of sales / Costo de venta | Selling expenses / Gastos de venta |
| `613` | `name@es` | Amortización contable | Depreciación contable |
| `614` | `name` | Accounting depreciation | Accounting amortisation |
| `701.06` | `name`, `name@es` | Interest on foreign bank charges / Intereses a cargo bancario extranjero | Interest payable by national natural persons / Intereses a cargo de personas físicas nacional |
| `702` | `name@es` | Utilidad cambiaria | Productos financieros |

### Why it is not cosmetic

The electronic accounting Chart of Accounts XML takes the `Desc` attribute of
every `<Ctas>` element from the *account group name* — `cfdicoa.xml`
(`t-att-Desc="account.get('name')"`), fed by `trial_balance.py`
`_l10n_mx_get_coa_values()`. Any `es_*` database therefore declares:

```xml
<catalogocuentas:Ctas CodAgrup="702" NumCta="702" Desc="Utilidad cambiaria" Nivel="1" Natur="A"/>
```

whereas the SAT catalogue (Anexo 24) publishes `702` as *Productos financieros*,
with `702.01 Utilidad cambiaria` … `702.10 Otros productos financieros` beneath
it. `CodAgrup` comes from `code_prefix_start` and stays correct, so the file
still validates against the XSD, but the declared description does not match the
official nomenclature. Trial Balance and Pólizas are unaffected — neither
exports group names.

### Evidence

- `252.07` contains its own XML ID as the Spanish name.
- `602` duplicates `501.01`, yet its children are `Sueldos y Salarios`,
  `Compensaciones`, `Tiempos extras`.
- `613` and `614` are swapped in one language each: `613`'s children are
  depreciations, `614`'s are amortisations.
- `701.06` duplicates `701.05` in both languages; the correct name is symmetric
  to `701.07` and to `702.06`.
- `6` is the only single-digit root group whose Spanish name does not match its
  XML ID (`account_group_gastos`).

### Notes

Introduced in d782b8b92557; correct in 15.0, where the names lived in
`account.account.tag.csv`. Still present in 18.0, 19.0 and master, hence
targeting 17.0. Template data only — existing databases are unaffected until the
chart is (re)installed, and renaming a group moves no balance.

Forward-Port-Of: odoo/odoo#277426

Forward-Port-Of: odoo/odoo#277891

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

# How to reproduce
- Activate the stock_landed_costs module
- Enable Dropshipping
- Create a product with :
	- Category :
		- Costing Method : AVCO
		- Inventory Valuation : Perpetual
	- Routes : Dropship
	- Atleast one vendor
- Create a SO for that product
- Confirm the SO & then Confirm the associated PO
- Login as an user with "User" rights for Inventory
- Try to validate the Dropship transfer

# The issue
You get an access error. If the same flow is done with a product with a Standard Price costing method, then the Dropship is properly validated

# Cause
When validating the Dropship, we'll call `_action_done` on the moves. This will trigger an update of the standard price of the product : https://github.com/odoo/odoo/blob/60bc7ae38e335958589c172df88e059bf0738cac/addons/stock_account/models/stock_move.py#L177 https://github.com/odoo/odoo/blob/60bc7ae38e335958589c172df88e059bf0738cac/addons/stock_account/models/stock_move.py#L345-L349

Since we're in avco, this will run the `_run_average_batch` method : https://github.com/odoo/odoo/blob/60bc7ae38e335958589c172df88e059bf0738cac/addons/stock_account/models/product.py#L675

That will fetch the value of each moves. For the Dropship moves, it'll do so by calling the `_get_value()` method :
https://github.com/odoo/odoo/blob/60bc7ae38e335958589c172df88e059bf0738cac/addons/stock_account/models/product.py#L486

This method will compute the value of the move, notably by using the associated landed costs : https://github.com/odoo/odoo/blob/60bc7ae38e335958589c172df88e059bf0738cac/addons/stock_account/models/stock_move.py#L431 https://github.com/odoo/odoo/blob/60bc7ae38e335958589c172df88e059bf0738cac/addons/stock_landed_costs/models/stock_move.py#L14

Now the issue is that this computation calls `_read_group` on 'stock.valuation.adjustment.lines' that are retricted to inventory administrators :
https://github.com/odoo/odoo/blob/60bc7ae38e335958589c172df88e059bf0738cac/addons/stock_landed_costs/models/stock_move.py#L11 https://github.com/odoo/odoo/blob/5f6fb63d5d7585805642c702d096b2f882e73761/addons/stock_landed_costs/security/ir.model.access.csv#L4

# Proposed solution
Get the value of the move in sudo like previously done in the flow : https://github.com/odoo/odoo/blob/60bc7ae38e335958589c172df88e059bf0738cac/addons/stock_account/models/stock_move.py#L314

opw-6323645

Forward-Port-Of: odoo/odoo#283420
Forward-Port-Of: odoo/odoo#273102

Version:
---------
- saas-19.2+

Steps to reproduce:
------------------------
- Install `mrp` module
- Create a BoM containing a component and a 60-minute operation duration
- Create an MO for that BoM with a quantity of 1 and save it.
- Change the quantity to 2.
- Click somewhere in the form to trigger the onchange.
- Change the quantity to 5.
- Try to Save the MO.

Issue:
Saving the Manufacturing Order can raise:

    AssertionError: Invalid falsy real id

Cause:
-------
Clicking somewhere after setting the quantity to 2 triggers an onchange; it does not save the MO yet.

During this onchange, Odoo works with virtual copies of the MO and its one2many move records. Recomputing the quantity can replace or remove one of these virtual component or finished moves.

When the onchange response is generated, `RecordSnapshot.diff()` compares the one2many value before and after the onchange:

https://github.com/odoo/odoo/blob/15dc1c48f2eeffaf444c88e94d16a952faa830e8/addons/web/models/models.py#L2280-L2283

For a removed one2many line, it generates the following command:

    Command.delete(id_.origin or id_.ref or 0)

A persisted move has an `origin`, so the command contains its database ID. However, a virtual move created during the onchange has neither an `origin` nor a `ref`. Its identifier therefore falls back to `0`.

For example, the onchange response can contain:

    'move_raw_ids': [
        (2, 0, 0),
        (1, 123, {'product_uom_qty': 2}),
    ]

In these commands:

- `(2, 0, 0)` means DELETE the virtual move whose ID became `0`.
- `(1, 123, {...})` means UPDATE the persisted move with ID `123`.

The web relational model applies and accumulates these commands in the form state while processing successive onchanges:

https://github.com/odoo/odoo/blob/15dc1c48f2eeffaf444c88e94d16a952faa830e8/addons/web/static/src/model/relational_model/static_list.js#L574-L691

After changing the quantity again to 5, the valid update is refreshed, but the deletion command for the discarded virtual record can remain. The final save payload can consequently be:

    {
        'product_qty': 5,
        'move_raw_ids': [
            (2, 0, 0),
            (1, 123, {'product_uom_qty': 5}),
        ],
    }

Saving the form calls `web_save()`, which forwards this payload to `mrp.production.write()`:

https://github.com/odoo/odoo/blob/15dc1c48f2eeffaf444c88e94d16a952faa830e8/addons/web/models/models.py#L79-L86

The resulting call flow is:

    mrp.production.web_save()
      -> mrp.production.write()
      -> BaseModel.write()
      -> One2many.write_real()
      -> flush()
      -> stock.move.browse([0])
      -> AssertionError: Invalid falsy real id

For a DELETE command, the one2many writer adds the command ID to `to_delete`. During `flush()`, it browses all collected IDs before unlinking them:

https://github.com/odoo/odoo/blob/15dc1c48f2eeffaf444c88e94d16a952faa830e8/odoo/orm/fields_relational.py#L1031-L1058

PR https://github.com/odoo/odoo/pull/227477 made browsing collections containing falsy real IDs invalid. This is intentional because `0` or `False` cannot identify a persisted database record.

FIX:
----

BackPort PR: https://github.com/odoo/odoo/pull/274755

it Fix payload.

After fix Payload:

<img width="612" height="517" alt="image" src="https://github.com/user-attachments/assets/856543b1-a466-44ff-bef8-df476234ac78" />

Before Fix Payload:

<img width="791" height="684" alt="image" src="https://github.com/user-attachments/assets/5be4a766-0c9d-4c80-8e16-2b6035f086cc" />

------

opw-6471907



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

Forward-Port-Of: odoo/odoo#284158

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

- 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

*=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. Create a quality control point on the Receipts operation type with Control per set to Operation.
2. Confirm a receipt of 2 units of the product: one pending operation quality check is created.
3. In the Barcode app, receive 1 unit and go back to the transfer with the back button.
4. The pending operation quality check is gone.

Issue
---
Going back from the Barcode app calls `post_barcode_process`, which on a partial reception splits the picked move into a done move and a remaining move, then merges the transient duplicate back with `_merge_moves`. https://github.com/odoo/enterprise/blob/b89614661682ecbd131d940539aac8afdd9d7289/stock_barcode/models/stock_move.py#L57-L60

`_merge_moves` cancels that transient duplicate through `_action_cancel` before unlinking it. https://github.com/odoo/odoo/blob/8f3100ca597559945cc42d9ef9517edbb40a900b/addons/stock/models/stock_move.py#L1400-L1401

The `quality_control` override of `_action_cancel`, picks the pending checks to drop from `is_product_canceled`, a `defaultdict(lambda: True)` keyed by `(picking, product_id)`. An operation check has no `product_id`, so its key is never computed by the loop and reads back the `True` default, so it is deleted even though the transfer still has a live move. Since an operation check covers the whole transfer, it must be dropped only when every move of its picking is cancelled. https://github.com/odoo/enterprise/blob/b89614661682ecbd131d940539aac8afdd9d7289/quality_control/models/stock_move.py#L68-L76

opw-6439179

Forward-Port-Of: odoo/enterprise#128767
Forward-Port-Of: odoo/enterprise#127427

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

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

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