Before this commit, MobileWebSuite.test_unit_mobile failed at random on the mail test "HtmlMail add icon and save inline html", which taps the save button of an html_mail field and waits for the write:

    [verifySteps] expected the following steps
    > Expected: [
      "web_save",
    ]
    > Received: []

This happens because a tap held longer than `LONG_TAP_DELAY` counts as a long press, and `_pointerUp` then dispatches no click at all. That delay spans the synthetic pointerdown and pointerup of a single `click()`, so the work a listener does during the press counts towards that delay: tapping save blurs the html field, which converts the whole editor content to inline styles, and under the load of a runbot build that conversion alone takes longer than the delay.

One solution could have been to raise `LONG_TAP_DELAY`, but a listener slower than the new value suppresses the click again.

This commit counts a tap as long only when the test releases the pointer itself, with `pointerUp`, so the work a listener does during a `click()` no longer suppresses the click.

https://runbot.odoo.com/odoo/error/946581

Forward-Port-Of: odoo/odoo#285640
Forward-Port-Of: odoo/odoo#284971

Description of the issue/feature this PR addresses:

When `im_livechat` (or any page) boots the OWL web stack with no `[data-hotkey]` / `withOverlay` targets, pressing Alt still called `preventDefault()` in `hotkey_service`. That blocked browser shortcuts such as Alt+D (focus address bar) on websites that embed the livechat scripts.

See https://github.com/odoo/odoo/issues/267928

Current behavior before PR:

- Pressing the overlay modifier (Alt, or Ctrl on macOS mapped to `"alt"`) always set `overlaysVisible = true` and called `preventDefault()`, even when there were no hotkeys to overlay.
- A follow-up key (e.g. D while Alt is held) then also hit `preventDefault()` because overlays were considered visible.
- Loading `/im_livechat/loader/...` + `assets_embed.js` on an external site therefore broke browser Alt shortcuts.

Desired behavior after PR is merged:

- `addHotkeyOverlays` returns whether overlays were actually displayed.
- `preventDefault` on the overlay modifier runs only when there is at least one overlay target.
- Pages with no hotkeys (typical livechat embed) leave browser shortcuts alone.
- When hotkeys exist, Alt still shows overlays and cancels the default, same as before.

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

Closing the chat with the ai agent on the ai_livechat snippet results in a chatwindow popping up which gives a bad user experience.

Steps to reproduce:
- Log in as Mitchell Admin.
- Go to website.
- Click on edit and choose `Contact & Forms`.
- Add the AI Livechat website snippet.
- From the snippet options, add an AI Agent and choose a livechat team. Make sure that Mitchell Admin is configured as an operator for that livechat team (livechat channel).
- Click on save.
- Open an incognito tab. Log in as Marc Demo.
- Go to Website.
- Type a message inside the `ASK AI` text area and press enter.
- Wait until you receive a response and then click close.
- A chat window will popup with the messages of the conversation with the AI along with a message saying `Visitor has left the channel`. This happens because `close` button will call `closeConversation` => `livechatService.leave()` => `visitor_leave_session` => `_close_livechat_session` that posts a message that the visitor has left the channel.

This commit solves the issue by setting the user who left the channel as the author of the `visitor left chat` message instead of OdooBot.

Currently, an error occurs when a user tries to view the WhatsApp Business account.

**Steps to Reproduce:**

 - Install the `whatsapp_oauth` module.
 - Go to `Settings` > `Languages` and add `French (BE)`, then `switch to it`.
 - Go to `WhatsApp` > `Configuration` > `WhatsApp Business Accounts (Comptes Whatsapp Business)`.

`ValueError: L'élément '<xpath expr="//div[contains(normalize-space(.), 'Receiving Messages')]">' ne peut être localisé dans la vue parente`

When the user changes the language, the text in the view is translated [1]. Since the WhatsApp 
account view tries to locate the div using the plain text Receiving Messages [2]. Since the text 
has been translated in the parent view, the XPath can no longer locate the element and raise 
the error.

This commit ensures that the XPath uses the name attribute to identify the element, which is 
language-independent. We cannot use the class attribute because the same class is used by 
other div elements.

[1]- https://github.com/odoo/enterprise/blob/a3db72899cb97612505aebbd5450aeb65205db73/whatsapp/views/whatsapp_account_views.xml#L81-L84

[2]- https://github.com/odoo/enterprise/blob/a3db72899cb97612505aebbd5450aeb65205db73/whatsapp_oauth/views/whatsapp_account_views.xml#L61-L63

7534862409

Before this commit, a build whose unit tests suite fails collects a second runbot error on top of the real one:

    odoo.addons.web.tests.test_js.WebSuite.test_unit_desktop.browser:
    Error received after termination: [MEMINFO] tests done (after GC)
    - used: 220535896 - total: 341990868 - limit: 4395630592

Note that the figures themselves are fine (220MB used of a 4.4GB limit): the error is not about memory, only about when the line is logged.

This happens because the runner logs that line after `stop()`, and `stop()` is what reports the suite result: the server settles the test on that report and kills the browser. The final major GC outlasts the report. A passing build escapes because the browser dies within milliseconds; a failing one stays up for the screenshot, long enough for the GC to finish and the line to land after termination.

This commit fixes the issue by moving `stop()` after the final cleanups and their memory log: the [MEMINFO] line is still logged, but before the result report, while the server still waits on the browser.

https://runbot.odoo.com/odoo/error/229655

Forward-Port-Of: odoo/odoo#284957

Steps to reproduce:
- Restaurant config with two POS devices on the same session
- Device A: open a table, add two products, press Order (the order is synced as a draft, its lines get server ids)
- Device A: remove both lines, without syncing
- Device B: touch the same order, so device A re-reads it from the server through the synchronisation websocket
- Device A: pay and validate the order

Issue:
The order is saved as paid, with its total and its payment, but without any orderline. The lines are deleted on the server: odoo.models.unlink: deleted pos.order.line records with IDs: [...]

Cause:
Removing an orderline queues an unlink command in
models.commands['pos.order'].unlink['lines_<order id>'] (delete_ in related_models.js). That command is only discarded by clearCommands(), which syncAllOrders() calls after a successful sync, so it stays pending in between.

Any read of the order in that window puts the line back: a deleted record counts as missing in missingRecursive(), so it is fetched again and loadData() re-creates it with its server id.

serialize() then emits both the update of the live line and the still pending unlink, and sync_from_ui writes
lines: [[1, id, {...}], [3, id]]. The ORM applies commands in order, and pos.order.line.order_id is ondelete='cascade', so Command.UNLINK deletes the line right after writing it.

Fix:
Skip a removal command when the record is still linked to the parent at serialization time. A record cannot be both linked and removed in the same payload, so the pending command is stale and dropping it keeps the local state. Genuine removals, where the record is no longer linked, are still sent.

opw-6401146

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

Forward-Port-Of: odoo/odoo#285427
Forward-Port-Of: odoo/odoo#284695

### Issue before this commit:
When clicking "Manage Models" from a bank statement line, the associated reconciliation models are not displayed when belonging to a foreign currency journal.

### Steps to reproduce the issue:
1. Download Accounting
2. Go to Currencies and activate another currency like EUR
3. Go to Journals and create a new one with bank type and curency EUR
4. Go to dashboard > new test bank journal created > 3 dots in the upper-right corner > Models > create a new one (ex Tester) setting the new test bank created as journal
5. Go to test bank journal and create a new bank matching
6. After the line is created click the 3 dots and go to Manage Models
7. See that the new model Tester created does not appear

### Cause of the issue:
Foreign currency journals append their currency to the display_name (e.g., "Bank (EUR)"). The JS search framework passes this full decorated string into the search domain. The backend then attempts to match "Bank (EUR)" exactly in the database name and code fields, which fails because the database name is "Bank" without the currency added.
https://github.com/odoo/odoo/blob/9c67949be529eb86886b3d5bde08e81e048ecfe7/addons/account/models/account_journal.py#L1095-L1100

### Reason to introduce the fix:
Perform an additional search using both the display_name and the clean name will fix the search functionality for foreign currency journals.

opw-6481970

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

### Issue before this commit:
In the bank reconciliation widget, the matched bill or invoice name is missing from the UI when a currency exchange difference occurs (e.g., when the payment date differs from the bill's exchange rate date).

### Steps to reproduce the issue:
1. Download Accounting and hr_expense_stripe
2. Go to currencies > euro > activate it and create a new rate (ex. 1.3 USD) with a previous date (ex. yesterday)
3. Go to Vendor Bills and create a new bill with:
	1. Bill date posterior to the currency rate creted
	2. EUR as currency
4. Go to Dashboard > Stripe Issuing
5. Crete a new bank matching with date previous than the date of the exchange rate created and the amount of the bill just created with minus sign
6. Reconcile it selecting the corresponding bill
7. The number of the reconciliated bill is not displayed

### Cause of the issue:
The field count_reconciled_lines_excluding_exchange_diff on account.move.line was incorrectly defined as a fields.Boolean instead of fields.Integer. As a result, the Python backend casts the line count to a boolean (true) before sending it to the frontend. The JavaScript widget performs a strict equality check (=== 1) on this value. Since true === 1 evaluates to false, the UI fails to fetch the correct move data and hides the origin bill's name.

### Reason to introduce the fix:
Changing the field type to fields.Integer is not stable so it has been decided to change the js file that was using it.

opw-6425896

Steps to produce:
---
- Create a company with `Argentina` as the country.
- Switch to the newly created company.
- Create a new website for the `Argentina company`.
- Create a pricelist with a `23%` discount on the sales price for all products.
- Create a new product, set the sale price to 100, remove all tax, and publish.
- Go to the website and switch to the newly created Argentina company website.
- Go to the Shop page and open the product.

Issue:
---
- The tax-excluded price (`Precio s/Imp. Nac.`) displayed on the shop catalog card differs from the tax-excluded price displayed on the product detail page.

Root cause:
---
- In `_get_additionnal_combination_info`, [1] returns the unit price with the pricelist discount already applied. However, when `combination_info['has_discounted_price']` [2] is `True`, the method applies the discount again manually, resulting in the pricelist discount being applied twice on the product detail page.

Solution:
---
- Remove the redundant discount calculation block. This ensures that the tax-excluded price displayed on the product detail page matches the price shown on the shop catalog card.

[1]https://github.com/odoo/odoo/blob/7f9560bd0ff66882459593a2d043c0197ceec0bb/addons/l10n_ar_website_sale/models/product_template.py#L61-L62
[2]https://github.com/odoo/odoo/blob/7f9560bd0ff66882459593a2d043c0197ceec0bb/addons/l10n_ar_website_sale/models/product_template.py#L71-L74

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

Forward-Port-Of: odoo/odoo#283761

Users who only have accounting rights (not the Settings > Users Companies > Access Rights group) get an access error on the Companies model when generating the BOE file for the Modelo 115 tax reports, even though exporting a BOE file has nothing to do with editing company configuration and should be available to any accountant.

Steps to reproduce:
-------------------
* Log in as a user with accounting rights only (not part of the Companies > Access Rights group)
* Go to Accounting > Reporting > Tax Return, open the Mod 115 report
* Click the gear icon > BOE > Generate BOE

> Observation:
An AccessError is raised: "You are not allowed to modify 'Companies' (res.company) ... This operation is allowed for the following groups:
Access Rights", even though the user is not trying to edit the company.

Why the fix:
------------
The BOE wizard shared by Mod 111/115/303 declares a `company_partner_id` field, related to `company_id.partner_id`, with `readonly=False`. That field is invisible in every view and only exists to compute the domain of `partner_bank_id`; it was never meant to be edited by the user. Because it is declared writable, the ORM attaches an inverse to the related field, so saving the wizard (which happens when generating the BOE, since the field, though invisible, is still part of the view and thus of the saved values) writes `company.partner_id` back onto `res.company`, even though the value never actually changes. That implicit write requires write access on res.company, which is only granted to the Access Rights group, causing the error for regular accountants. Dropping `readonly=False` keeps the field as a plain readonly related field, still usable for the bank account domain, without ever triggering that spurious write.

opw-6388869

Forward-Port-Of: odoo/enterprise#129841
Forward-Port-Of: odoo/enterprise#126661

Currently, users encounter discrepancies between the reordering rule and forecast quantities when products are in inter-warehouse transit.

## Steps to produce:
- Install Manufacturing and Sales
- Enable Multi-Step Routes and MTO from settings.
- Create a warehouse with 3 steps manufacturing and Short Name: WH2
- Go to warehouse 1 and Enable `Resupply From: My Company - warehouse # 2`
- Routes > Open the resupply route >  click WH2/Stock -> Inter-warehouse transit
- Set supply method to 'Take From Stock, if unavailable, Trigger Another Rule' and save.
- Create a tracked product 'Generic Chair' with both MTO and warehouse resupply route enabled.
- Create an empty Manufacturing BoM for the `Generic Chair`
- Create a manual reordering rule  for chair with
   - location: WH2/Stock 
   - Min:5 and Max: 10
- Create and confirm a sales order for chair with quantity 1.
- Open the related manufacturing change the quantity to 5 and confirm it.
- Open the forecast report for chair in warehouse 2 the forecasted quantity is 4
- Open the reordering rule and observe the forecasted quantity.

## Observed behavior:
The forecast report for the chair in the reordering rule shows -1, even though 5 units are expected from the manufacturing order. This is inconsistent with the forecast report and could cause errors when reordering the generic item.

## Root cause:
When the user changes the quantity in a Manufacturing Order (MO), the write method is called with values such as:

`[[2, 9], [0, 'virtual_14', {...}]]`

As a result, the existing `move_finished_ids` records are unlinked and recreated using only the field values that are present in the MO form view.

Since the Final Location field in `move_finished_ids` is not present in the MO form view, its value is not included when `move_finished_ids` is recreated.

Consequently, the create method of the stock.move model applies the default value at [1] and sets the final destination location to:

`WH2/Stock → Post Production`

This changes the `location_final_id` of the finished move to Post Production.

When the user opens the Forecast Report for the warehouse, `_get_report_data` searches for incoming and outgoing quantities across all child locations of the warehouse at [2]. Since Post Production is included in the warehouse's child locations, its quantities are correctly included in the forecast report.

However, reordering rules work differently. They calculate quantities only for the specific location configured on the orderpoint, which in this case is WH2/Stock

At [3], because `location_final_id` of `move_finished_ids` is set to Post Production, and Post Production is not a child location of WH2/Stock, the incoming quantity from this move is not included in the reordering rule calculation.

As a result, the forecasted quantity is calculated as -1 (outgoing) instead of 4, which leads to the reported issue.

[1]-
https://github.com/odoo/odoo/blob/5e84fdd99e34836a15cadc4fdf4b6bc449727e58/addons/mrp/models/stock_move.py#L278-L279 
[2]-
https://github.com/odoo/odoo/blob/5e84fdd99e34836a15cadc4fdf4b6bc449727e58/addons/stock/report/stock_forecasted.py#L156-L168 
[3]-
https://github.com/odoo/odoo/blob/c4de5361fb207916175332dcf6815c0814ecf09c/addons/stock/models/product.py#L437-L441

## Solution:
Keep the final location ID set during the initial quantity change if it already exists on the manufacturing order, since the order will ultimately end up in WH2/Stock as its final location in the chain. This ensures consistent forecast quantities between the reordering rule and the forecast report, while also keeping the final location consistent across the manufacturing order and its finished stock moves.

opw-6432985

### Steps to Reproduce:
1. In Debug mode, go to Aliases
2. Click on any active Alias, ex. customer-care
3. Click on "Open Parent Document" smart button
4. Click on "Tickets" smart button and observe error

### Description of the issue/feature this PR addresses:
**Issue:** When navigating from an email alias to its parent document (e.g., a Helpdesk Team), the web client incorrectly retains the  `active_id` and `active_model` of the alias in the context.

**Solution:** We updated the `action_view_ticket` method in `helpdesk.team` to explicitly inject the correct `active_model` and `active_id` into  the context before calling `_for_xml_id`. This overwrites the polluted Alias data before the window action is evaluated.

### Current behavior before PR:
Clicking the "Tickets" smart button passes the old alias context into the action. This bad data flows into the ticket view, which attempts to look up a Helpdesk Team using the Alias's ID to generate the empty list help message, resulting in a `MissingError`.

### Desired behavior after PR: 
The Python action sanitizes the context at the source, ensuring that the XML action and subsequent view evaluations receive the correct Helpdesk Team ID. Ultimately, the view will load normally without crashing.

opw-6395638

Forward-Port-Of: odoo/enterprise#129669
Forward-Port-Of: odoo/enterprise#125232