Steps to reproduce
------------------
1. On a peruvian company, set a cash rounding method on an invoice
2. Post the invoice and generate the SUNAT UBL 2.1 XML

-> the rounding is in `PayableRoundingAmount` but `PayableAmount` still
   has the amount before rounding!

Why it's happening
------------------
The generic code computes `PayableAmount` from `amount_residual`, and Peru overrides it to be the total tax included of the XML minus the prepaid amounts, because the residual can not be used there.

Then odoo/odoo@b847552872ad changed the meaning of the totals. The cash rounding line is not part of the base lines anymore, its amount is kept aside in `cash_rounding_base_amount_currency` and the totals do not contain it anymore.

The generic code stays correct because `amount_residual` already has the rounding inside but the Peru total using `tax_inclusive_amount_currency` is now the amount before rounding and this is what ends up in the `PayableAmount`!

The fix
-------
Add the cash rounding amount when computing the `PayableAmount`.

opw-6509677

Forward-Port-Of: odoo/enterprise#130732
Forward-Port-Of: odoo/enterprise#129983

Accessing an order on the website without connecting (only with the access token) doesn't allow the user to return the order (nothing happens when click on the "Return" button)

Steps to reproduce:
1. Install Sales and Inventory
2. Go to Settings > Inventory > Operations and enable "Allow Spontaneous Returns"
3. Go to Sales and create a new quotation for customer "Acme Corporation" with product "Acoustic Bloc Screens" and confirm it
4. Go to the related delivery, set the quantity to 1 and validate it
5. Go back to the sale order and click the "Preview" smart button
6. Copy the url (/my/orders/<id>?access_token=...) and open it in an incognito window
7. Click the return button on the order page
8. Nothing happens

Issue:
The route to `my_order_return_data` requires the user to be logged in

Solution:
Make the routes `my_order_return_data` and `order_return_label` public
For 19.4: access `return.reason` records with sudo (should be removed in master)
For master: add read right on `return.reason` for all users

opw-6487767

Forward-Port-Of: odoo/odoo#285290

## [FIX] l10n_fr_reports: fix missing lines in association balance sheet

### Issue:
The Active part of the Balance Sheet for associations shows an incorrect `TOTAL ACTIVE` — some accounts are not propagated to their parent aggregations

### Cause:
`ACTIF_IMMOBILISE` was missing `BIEN_PAR_DONATION` in its formula
`ACTIF_CIRCULANT` was missing both `DISPONIBILITES` and `INSTRU_FINAN` in its formula

### Steps to reproduce:
- Install `l10n_fr_reports` and `accountant`
- Create a new FR asso company and switch to it
- In Accounting Settings, select:
  France - Associations accounting plan
- Create a Journal Entry:
  Account: 240000, Debit: 100 (BIEN_PAR_DONATION)
  Account: 512001, Debit: 100 (DISPONIBILITES)
  Account: 520000, Debit: 100 (INSTRU_FINAN)
  Account: 509000, Credit: 300
- Open the Balance Sheet and select Balance Sheet for associations

Before the fix, `TOTAL ACTIVE` is 0 instead of 300

--------------

## [FIX] l10n_fr_reports: add force_date_scope to asso cross_report

### Issue:
The Passive part of the Balance Sheet for associations shows an incorrect `TOTAL PASSIVE` — the same move line is counted twice, once in `Retained earnings` and once in `Profit or loss for the year`

### Cause:
In 19.1, `cross_report` aggregations were refactored: https://github.com/odoo/enterprise/commit/e699a14a1922d6b8a5bc6b88ad9c02a411e4b073
By default, a `cross_report` no longer forces its `date_scope` to the terms it calls — `force_date_scope` must now be explicitly passed in the subformula
The association balance sheet was added in 19.1 without this parameter, so `RESULT_LEXERCICE` (`from_fiscalyear`) and `REPORT_NOUVEAU` (`to_beginning_of_fiscalyear`) both used the current report's `date_scope` instead of their own
This caused both expressions to match the same entries and double the `TOTAL PASSIVE`

### Steps to reproduce:
- Install `l10n_fr_reports` and `accountant`
- Create a new FR asso company and switch to it
- In Accounting Settings, select:
  France - Associations accounting plan
- Create a Journal Entry:
  Account: 512001, Debit: 100
  Account: 701100, Credit: 100
- Open the Balance Sheet and select Balance Sheet for associations

Before the fix, `TOTAL PASSIVE` is 200 instead of 100

opw-6520639

Forward-Port-Of: odoo/enterprise#130147

Since the removal of tracking values, they are only accessible formatted and localized embedded into mail messages. This means when we try to check them in tests, we need to format the "reference" values using the same locale.

During testing the locale is *generally* `en_US` because that's the default for odoo / test users, but `TransactionCase.env` does not have a lang configured at all, so when tracking we call something like `babel_locale_parse(self.env.lang)` = `babel_locale_parse(None)`.

`None` is obviously not a valid locale, so `babel_locale_parser` ~~raises an error~~ falls back, and the first fallback is `Locale.default()`, which checks the language / regional envvars (`LANGUAGE`, `LC_LANG`, `LC_ALL`, `LANG`) and returns the first valid one, otherwise `babel_locale_parse` then defaults to `en_US`.

The middle case is the problem here, if a machine is configured with a locale other than `en_US` then that's what's used to format the tracking values against the stored message, so if someone's locale is `zh_TW` they get `2020年1月1日`, which for some reason does not match a english-US format, making pretty much every test checking tracking values fail.

But hey for once it's not a babel version issue.

Steps to reproduce:
- Create a pricelist with a rule applied on a product category and make it available in the PoS
- Open a PoS session
- From the backend, create a product in a new category covered by such a rule
- Back in the PoS, find that product through Search > Search more and add it to the order

Issue:
The product is priced at its sale price, the pricelist rule set on its category is ignored.

Cause:
A product that is not part of the initial payload is loaded on the fly by load_product_from_pos, which sends back the rules returned by get_pos_ui_product_pricelist_item_by_product. That domain only matches the rules set on the template or on the variant, never the ones set on a product category, and the payload carries no product.category record either. The client therefore has neither the rule nor the category: parentCategories walks categ_id, which resolves to nothing, so getCategoryRulesIds returns no rule and getPrice falls back to the sale price.

This stayed unnoticed because product.category is fully loaded when the session starts, along with every category rule, so only the categories created after the session was opened are missing.

Fix:
Send the categories of the loaded products, since a rule set on a parent category applies to its children - along with the products, and match the rules set on those categories in get_pos_ui_product_pricelist_item_by_product.

The initial loading domain of product.pricelist.item no longer filters the category rules on the loaded categories: such a rule has to be loaded whatever the products sent to the client are, since a product of that category may be loaded later on.

opw-6477745

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

Forward-Port-Of: odoo/odoo#285721
Forward-Port-Of: odoo/odoo#284660

Steps to reproduce:
- Argentinean company, Responsable Inscripto (l10n_ar_pos installed)
- A posted customer invoice with VAT, partially paid
- In the PoS, pick the customer, "Settle invoices", select that invoice, pay the balance by bank transfer and validate

Issue:
Validation fails with "There should be a single tax from the "VAT" tax group per line, but this is not the case for line ..." and the settlement cannot be recorded at all. The invoice being settled is correct; the rejected line belongs to a second invoice the PoS creates for the settlement itself.

Cause:
`setToInvoice` already refuses to invoice a settlement, but its condition, `is_settling_account and no line`, only describes a deposit: the deposit line is added at validation. When settling a due or an invoice, `is_settling_account` stays false and the order does carry lines - the settle lines - so the guard never fires. l10n_ar_pos then sets `to_invoice` on mount, as a sale must generate an electronic document in AR, and the settle line, untaxed on purpose since it pays an existing document rather than selling anything, reaches `_check_argentinean_invoice_taxes`.

Fix:
Refuse the flag as well when every line is a settle line. Such an order generates an empty document - all its lines, the receivable one included, have a zero balance - so it records nothing and only consumes a document number, which in AR means an AFIP number for a zero-amount invoice. An order that also sells something keeps its invoice, since the sale still has to be reported. Reconciliation is unaffected: it happens in `_reconcile_account_move_lines` at session close, and is already covered for both invoiced and non-invoiced settlement orders.

opw-6464675

Forward-Port-Of: odoo/enterprise#129902
Forward-Port-Of: odoo/enterprise#128975

A chat between 2 persons should be unique, but it can currently be created multiple times because we don't have a proper constraint.

A lock could be added in the main create route, but it wouldn't catch all flows, and it would also slow down the route and potentially create unnecessary retries.

The best way to ensure uniqueness is to add a proper SQL constraint. As the combination of members depends on a x2many relational field, a new field is added to track this combination on the channel table. This is a similar pattern as combination_indices on product.product.

The new field is computed during create and not with a compute:

- compute are computed after creating the record in database, which makes it impossible to have SQL constraints to ensure the field is properly set, as it would initially not be set
- chat with a partner that later gets deleted should be kept for history, in this case the member is deleted but the channel remains, re-computing the member_indices could lead to several channels with only the current user in it, which the constraint does not allow.

This also significantly simplifies the search of existing chat channels.

task-4664353

https://github.com/odoo/upgrade/pull/9120

When unreconciling a payment from an invoice with a cash basis tax,
the tax cash basis (CABA) entry is reversed. The reversal is supposed to
land in the same period as the origin entry so the tax report nets to
zero for that period.

Steps to reproduce:

- Enable cash basis and create a cash basis tax (exigibility on payment)
- Post an invoice dated in the past with that tax
- Reconcile a bank statement line to the invoice
- Resequence the cash basis entry so the month is dropped from the
  name (CABA/08/2026/0001 -> CABA/2026/0001)
- Unreconcile the statement line

Issue:

The reversal CABA entry created on the last unreconcile is dated today
instead of the origin entry's month. In the tax report the original tax
amount stays in the statement's month while the reversal amount appears
in the current month, so the two no longer cancel out.

Analysis:

While under a monthly journal sequence a past date returns
the last day of that month, under a yearly sequence a past date within
the current year returns the latter between the move date and today,
moving the reversal out of the origin period.

opw-6301553

Forward-Port-Of: odoo/odoo#284840
Forward-Port-Of: odoo/odoo#281250

Versions
--------
19.0 and later

Steps
-----
- Install `sale_stock_renting`.
- Go to Rental > Orders > Rental Schedule.
- Create a new rental order line from a cell of the gantt view, on a row grouped by a storable rentable product.

Issue
-----
The first line of the description of the created line is named "Bike (3 items)" instead of "Bike".

Cause
-----
The `display_name` override adding that quantity is keyed on the `in_rental_schedule` context key. That key is set on the `action_rental_order_schedule` action itself, so it is part of the search context and is propagated to every record, dialog and dropdown opened from the schedule, while it is only meant to flag that we are in the schedule (default values conversion, hidden onchange buttons, group expansion, ...).

Solution
--------
Introduce a dedicated `display_renting_stock_quantity` context key and depend on it instead when fetching data to build the gantt rows, leaving the records opened from the schedule with their regular display name.

Forward-Port-Of: odoo/enterprise#130651
Forward-Port-Of: odoo/enterprise#130322

Steps to reproduce:
- open Discuss, open any chat, open the emoji picker (no 'Frequently used'
  emojis)
- search a term and select emojis without closing the picker (shift+click on
  desktop, plain click on mobile)
- clear the search with backspace

=> traceback: 'Cannot read properties of null (reading
`getBoundingClientRect`)' in adaptNavbar().

This happens because when we clear the search input it calls
`highlightActiveCategory()`, which sets `categoryId` to the topmost category of
the grid, which is now the 'Frequently used' category (sortId 0), added to the
picker since the emojis we just picked updated the recent state. To update the
navbar, `currentNavbarPanel` then looks for the panel holding it in
`emojiNavbarRepr`, but that representation is only built in `adaptNavbar()`,
which runs on mount and from the `ResizeObserver` only, so it was built without
the 'Frequently used' category and no panel contains it. It returns undefined,
the navbar renders empty, its size change wakes the `ResizeObserver`, and
`adaptNavbar()` crashes on querySelector('.o-Emoji').getBoundingClientRect()`.

This commit solves the issue by rendering the `recentEmojis` from a snapshot
taken when the picker is opened, so they are not added to the picker while the
while `emojiNavbarRepr` does not contain their category id.

partial backported PR: https://github.com/odoo/odoo/pull/281104

Task-[6204249](https://www.odoo.com/odoo/project/1519/tasks/6204249)



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

Forward-Port-Of: odoo/odoo#287126
Forward-Port-Of: odoo/odoo#284372

`l10n_my_edi_state` on the invoice was left empty whenever the related document wasn't in an "active" state (`valid`/`rejected`/`in_progress`), even once it reached a terminal outcome like `cancelled` or `invalid`. As a result, the form and list view showed no MyInvois status at all for those invoices, making them look like they were never sent to MyInvois - even though the underlying `myinvois.document` clearly was.

Instead of deriving `l10n_my_edi_state` purely from the active document, fall back to a cancelled/invalid document when no active one exists, so the invoice always reflects its real MyInvois status. Since the state can now be `invalid`/`cancelled` (truthy) instead of always empty, every place that used to treat a falsy `l10n_my_edi_state` as license to send/resend is updated to also allow `invalid`/`cancelled`, since those are equally free to resend: `_compute_show_reset_to_draft_button`, `action_l10n_my_edi_send_invoice`, and the "Send To MyInvois" button/field visibility in the view.

`l10n_my_invoice_need_edi` also used `l10n_my_edi_state` in its computation, purely to exclude `rejected` invoices (which still have an active document blocking a new send). That state check is now handled directly by each caller instead: the field is renamed to `l10n_my_edi_is_applicable` and reduced to the structural question of whether MyInvois applies to the invoice at all (posted, MY, proxy user configured), while `_compute_highlight_send_button` checks `l10n_my_edi_state != 'rejected'` explicitly.

task-6442567

This PR fixes the moves (and their picking) `location_id` to be more accurate after applying push rules on the moves.

Before this PR:
The new move introduced from push rules (and its new picking) would have the `location_id = old_move.location_dest_id` which could be a parent of the location_dest_id of the old move_lines which is more accurate.

For example, if a move has a `location_dest_id = 'stock'` and the user changes the move_lines of that move so that `move_lines.location_dest_id = 'stock/sublocation'`. When push rules are applied on the move_lines,
`new_move.location_id = old_move.location_dest_id = 'stock'`. But, it should be `new_move.location_id = 'stock/sublocation'`.

After this PR:
The new move now (and its picking) will have the `location_id` set as the `rule.location_src_id` or `old_move.location_dest_id` just in case the `old_move.location_dest_id` is a sublocation of `rule.location_src_id` which gives a more accurate source location for the move and the picking.

Task-6226781

Steps to reproduce:

- Click in the input of a datetime picker (with an existing value)
- Manually edit the text in the input
- Press Escape

Current behavior:

- The manually typed value is parsed and validated, exactly as if Enter had been pressed instead.

Expected behavior:

- Escape should discard the edit and restore the field's previous value, closing the picker without applying any change. This is how other dropdown-based fields (e.g. many2one) behave.

Solution:

- On Escape, reset the input(s) to the current (unedited) value instead of parsing the typed text. If the popover is open, let its own "closeOnEscape" hotkey close it (avoids a double-close race with our own close call); otherwise close/apply directly, since there is no such hotkey to rely on.

Also, Ctrl+Enter had a dedicated behavior: it validated the typed value and re-opened/kept the picker open, refreshing its content to reflect the newly entered date. This is removed, so Ctrl+Enter now behaves like a plain Enter (validates and closes).

task-6537497

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

**Issue**
If a move's package is already reserved, relocating that move raises an AccessError.

**Steps to reproduce**
- Activate the "Packages" feature in Inventory settings.
- Activate track localization in settings
- Create a new storable product.
- Using an inventory adjustment, add some quantity of that product in Stock, in a new package X.
- Create a sales order for that product and confirm it, so the quantity in Stock gets reserved.
- Go to Inventory > Reporting > Locations.
- Select the quant and try to relocate it, e.g. to WH/Input.
-> Raises an AccessError: "Failed to write field stock.package.picking_ids"

**Cause**
Relocating a quant creates a move:
https://github.com/odoo/odoo/blob/b9eb72eb1d3be841396cd5dcce827ec88ed9ee31/addons/stock/models/stock_quant.py#L1531
which creates a new move line without a `picking_id`:
https://github.com/odoo/odoo/blob/b9eb72eb1d3be841396cd5dcce827ec88ed9ee31/addons/stock/models/stock_quant.py#L1276-L1287

Since both move lines (the new one and the one linked to the SO delivery) share the same `result_package_id`,
in `_compute_picking_ids`, both move lines are grouped:
https://github.com/odoo/odoo/blob/b9eb72eb1d3be841396cd5dcce827ec88ed9ee31/addons/stock/models/stock_package.py#L174-L176
Thus, two "pickings" end up associated with the package: the SO's, and `None`.
While setting those pickings on the package, it tries to access them:
https://github.com/odoo/odoo/blob/b9eb72eb1d3be841396cd5dcce827ec88ed9ee31/addons/stock/models/stock_package.py#L182
https://github.com/odoo/odoo/blob/b9eb72eb1d3be841396cd5dcce827ec88ed9ee31/odoo/orm/fields_relational.py#L1497-L1503
And since `self` isn't just `None`, this check won't be skipped:
https://github.com/odoo/odoo/blob/b9eb72eb1d3be841396cd5dcce827ec88ed9ee31/odoo/orm/models.py#L4152
This eventually raises an AccessError since `None` gets filtered out by `filtered_domain`:
https://github.com/odoo/odoo/blob/b9eb72eb1d3be841396cd5dcce827ec88ed9ee31/odoo/orm/models.py#L4154-L4156
https://github.com/odoo/odoo/blob/b9eb72eb1d3be841396cd5dcce827ec88ed9ee31/odoo/orm/fields_relational.py#L1504-L1505

opw-6427070

Forward-Port-Of: odoo/odoo#283937
Forward-Port-Of: odoo/odoo#282209

_get_invoice_counterpart_amls_for_early_payment_discount_per_payment_term_line
only split the early payment discount amount per invoice line (and thus
preserved each line's own analytic distribution) when the payment term's
early_pay_discount_computation was "included".
For "mixed" and "excluded", it instead built a single counterpart line,
discarding the analytic distribution of the invoice lines.

Compute the per-invoice-line base amounts (and the corresponding price_unit
for "mixed") for all three computations, keeping only the tax
calculation restricted to "included". This way "mixed" and "excluded" discount
entries now keep the analytic distribution of the invoice line they come
from, while behavior for "included" is unchanged.

Steps:

- Create 3 payment terms with EPD, each one with a different
  `early_pay_discount_computation` setting
- For each payment terms, create one invoice with two lines, only one
  having an analytic distribution
- Confirm and pay the 3 invoices (early payment, discount applied)

Issue:

For 'mixed' and 'excluded', the discount line is the sum of the discount
from the 2 invoice lines, and the analytic distribution is lost.

opw-6380278

Forward-Port-Of: odoo/odoo#286816
Forward-Port-Of: odoo/odoo#282541

**Issue:**

During migration to Odoo 19, the SA tax tag migration logic is present in: "migrations/2.1/pre-migrate.py" was not executed during the migration of databases because this:
  * SA compact tax tags were not renamed
  * VAT tax grids still use old tags
  * Localization reload was partially updating taxes
  * manual intervention was required

Added logs/debugging in:
* 2.1/pre-migrate.py
* 2.1/end-migrate.py
* 2.2/end-migrate.py

- Verified in both local and customer databases that only the 2.2 migration path was executed during upgrade, while the 2.1 migration scripts were skipped because the Odoo 19 manifest upgrade path already targeted the 2.2 migration version.
- 19:https://github.com/odoo/odoo/blob/67510fd36f7af31f83ef110602f9922ed5a43024/addons/l10n_sa/__manifest__.py#L6

**Solution:**

- Bumped the l10n_sa module version to 2.3 to apply these changes to databases that are already in production.
- Moved `migrations/2.1/pre-migrate.py` to `migrations/2.3/pre-migrate.py` to ensure the SA tax tag migration logic is executed during the `2.3` upgrade flow.
- Moved `migrations/2.2/end-migrate.py` to `migrations/2.3/end-migrate.py` to align with the `2.3` version bump and refresh the SA tax mappings correctly during migration.
   * SA tax tags migrate correctly
  * VAT tax grids update automatically
  * invoices use new tags correctly
  * No manual localization reload required

OPW - [6117408](https://www.odoo.com/odoo/project/70/tasks/6117408), [6224788](https://www.odoo.com/odoo/project/70/tasks/6224788)

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#264571

### Problem

When an AI agent includes a document source whose underlying `ir.attachment`
has `res_field` set (e.g., an invoice PDF generated from a Sale Order),
triggering **Update With AI** from **Website → Site → Optimize SEO**
raises a `KeyError` in `_build_rag_context`.

### Steps to Reproduce

1. Open the **AI** app.
2. Configure the **Odoo Agent**.
3. Add a source → **Add From Documents**.
4. Select a document whose underlying `ir.attachment` has `res_field` set
   (e.g., an invoice PDF generated from a Sale Order).
5. Go to **Website → Site → Optimize SEO**.
6. Click **Update With AI**.
7. Observe the following error:

```
KeyError: 'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
```

[Video](https://drive.google.com/file/d/1AAg0AvC3TRQzMLhI9hWFuSarOTHzQE-b/view?usp=sharing)

### Root Cause

In `ai/models/ai_agent.py`, `_build_rag_context()` retrieves the
`ai.agent.source` records corresponding to the embeddings by searching on the
attachment checksum:

```python
agent_sources = self.env["ai.agent.source"].search([
    ("attachment_id.checksum", "in", embeddings_attachment_checksums),
    ("agent_id", "=", self.id),
])
```

This domain traverses `attachment_id.checksum`, which internally calls
`ir.attachment._search()`.

As part of the standard attachment search behavior,
`ir.attachment._search()` automatically injects a
`('res_field', '=', False)` filter unless:

- `skip_res_field_check=True` is set in the context,
- the domain explicitly references `id` or `res_field`, or
- `bypass_access` is enabled.

```python
domain = Domain(domain)
if (
    not self.env.context.get("skip_res_field_check")
    and not any(d.field_expr in ("id", "res_field") for d in domain.iter_conditions())
    and not bypass_access
):
    disable_binary_fields_attachments = True
    domain &= Domain("res_field", "=", False)
```

[Reference](https://github.com/odoo/odoo/blob/19.0/odoo/addons/base/models/ir_attachment.py#L630)

Because of this implicit filter, attachments with `res_field` set are excluded
from the search. Consequently, `agent_sources` does not contain all the sources
corresponding to the retrieved embeddings.

Later, `_build_rag_context()` builds a checksum-to-source mapping:

```python
source_map = {
    source.attachment_id.checksum: source
    for source in agent_sources
}

for embedding in similar_embeddings:
    checksum = embedding.attachment_id.checksum
    agent_source = source_map[checksum]
```

Since `source_map` is built from the incomplete `agent_sources` recordset, it is
missing entries for attachments filtered by `ir.attachment._search()`.
However, `similar_embeddings` still contains embeddings for those attachments.

As a result, the lookup:

```python
agent_source = source_map[checksum]
```

raises a `KeyError`.

### Solution

Bypass the implicit `res_field` filter when searching `ai.agent.source`:

```python
agent_sources = (
    self.env["ai.agent.source"]
    .with_context(skip_res_field_check=True)
    .search([
        ("attachment_id.checksum", "in", embeddings_attachment_checksums),
        ("agent_id", "=", self.id),
    ])
)
```

This ensures that all `ai.agent.source` records matching the requested
attachment checksums are returned, including those referencing attachments with
`res_field` set. As a result, `source_map` contains all expected entries and
`_build_rag_context()` no longer raises a `KeyError`.

opw-6379816

Forward-Port-Of: odoo/enterprise#129999
Forward-Port-Of: odoo/enterprise#125780

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`, open settings and turn on `Product Reference Price` and `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 addition of a feature that shows product's unit price on website (check [PR]).
- As the user deleted all the variants of the product `test`, when trying to get the unit price of the product's variants [1] causes this error to occur.

Solution:
- If the product doesnt have any variants we should get the unit price from the product template itself.

[PR]: https://github.com/odoo/odoo/pull/254309

[1]: https://github.com/odoo/odoo/blob/22ede9cd601f54ebf248a7ddace433746f066e68/addons/website_sale/models/product_template.py#L686

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

Forward-Port-Of: odoo/odoo#282945

ChatHub's cleanup (the shared `subscribeToStorage` listener) only ran when something explicitly called `store._runDisposeFns()`. Only mail's own test helper did that; any other app embedding `mail.store` (point_of_sale, pos_self_order, ...) never disposed it, so `subscribeToStorage` kept one stale callback per undisposed ChatHub, unbounded.

Hook disposal into the services registry's "CLEANUP" event instead, which Owl already fires on every app teardown regardless of embedding (same pattern as `profiling_service.js`). Converting `storeService` to an Owl plugin using its own `onWillDestroy` (see TODO) would be the cleaner long-term fix.

Measured via hoot's [MEMINFO] on the self_order_service suite that exposed this leak, same db/commit, only the fix toggled:

| suite                                                   | before (MB) | after (MB) |      % |
|---------------------------------------------------------|------------:|-----------:|-------:|
| pos_self_order/services/self_order_service (30 tests)   |       253.8 |      155.6 | -38.7% |
| pos_online_payment_self_order/self_order_service        |       253.1 |      155.0 | -38.8% |
| pos_self_order_event/self_order_service                 |       253.2 |      155.1 | -38.7% |
| pos_self_order_iot/self_order_service                   |       260.1 |      162.0 | -37.7% |
| tests done (final)                                      |       251.9 |      153.8 | -38.9% |

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