**Steps to reproduce:**
- Install Accounting
- In Accounting settings, activate "Intrastat"

- Create a product with Intrastat info
- Create a bill:
  * Product: [the created Intrastat product]
  * Intrastat Country: [any]
  * Intrastat Transport Mode: [any]
- Confirm the bill
- Make sure that the bill name contains a hyphen character (i.e. "-")
For example, "BILL/2026-06/0001".
Use the "Resequence" action from the bills list view if needed.

- Go to "Accounting / Reporting / Audit Reports / Intrastat Report"
- Expand the line to display the bill name

**Issue:**
The bill name is not fully displayed.
It is cropped right before the hyphen character (i.e. BILL/2026).

**Cause:**
A regex is used to retrieve the bill name from the report line name, but it is only allowing "/" character.

**Solution:**
Just allow "-" character in addition.
No other character is allowed to limit the risk of matching something that should not.

opw-6299854

Forward-Port-Of: odoo/enterprise#120979

## Issue
When using the Timesheets systray, if we set a project after clicking the *Save* or *Reset* button, the project is not saved after closing the systray.

## Steps to reproduce
1. Install *Timesheets* (`timesheet_grid`)
2. Open the Timesheets systray
3. Click *Reset* and set a description, a project and/or a task, then close the systray
4. Open the systray again
5. **The description/project/task set in step 3 do(es) not appear anymore.**

## Cause
Commit https://github.com/odoo/enterprise/commit/b9b7f8a0acf7a1c545c6613cf8bbc29871632e26 introduced the `preventUnmountSave` attribute. The attribute is set to `true` after saving and discarding an entry. When the systray is unMounted, the manual values (e.g., description, project and task) are not saved if the attribute is set to `true`:

https://github.com/odoo/enterprise/blob/7cd8dd008eb88d6c12f3e65fb8d311058290a301/timesheet_grid/static/src/components/timesheet_timer_inline_form/timesheet_timer_inline_form.js#L171-L174

## Fix
After discussing with the author of the previous commit, it appears this was done to prevent an issue with values stored in cache, but that issue does not seem to occur anymore, which leads to believe that the attribute is not required anymore.

opw-6284016

Forward-Port-Of: odoo/enterprise#122332
Forward-Port-Of: odoo/enterprise#121605

### Steps to reproduce the issue:
1. Download Accounting and l10n_it_edi_withholding
2. Switch to IT company
3. Create 2 taxes with a Pension fund type set (in Advanced Options)
4. Create an invoice and set on the same line the 2 taxes created
5. Click on send and print and see the error: Invoices must have at most one Pension Fund tax set per line. (even if it's not true)

### Cause of the issue:
The following function check how many taxes we have per line but this limit is incorrect because it is accepted by the Italian electronic invoicing specifications to have also more than 1 tax. 
https://github.com/odoo/odoo/blob/bd095fe286930acc54d85bdf7f92af15569f5b82/addons/l10n_it_edi/models/account_move.py#L1268-L1273

### Reference documentation:

1. [Art. 10 della Legge n. 183_2011, successivamente integrato dal D.L. n. 1_2012 (art. 9-bis)..pdf](https://github.com/user-attachments/files/29056003/Art.10.della.Legge.n.183_2011.successivamente.integrato.dal.D.L.n.1_2012.art.9-bis.pdf)

2. Following image:
<img width="823" height="580" alt="estrattoEppi" src="https://github.com/user-attachments/assets/e79be16f-651e-467a-84f4-8400185ceea4" />


opw-6264685

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

Forward-Port-Of: odoo/odoo#273040
Forward-Port-Of: odoo/odoo#269456

Currently on the pos payment method form, if you click "Select more" on the journal field, you will see two buttons 'New' & 'Create New'.

Steps to reproduce:
-------------------
* Open any pos payment method
* Select the journal field
* Select "Search more"
> See two creation buttons

Why the fix:
------------
One button is the standard "On search more" button which can be hidden using options such as no_create, no_create_edit, ...

The second button is defined on the list view for journals and since the search more uses the list view it shows the button as well. Currently we can do that with a context key to ensure that on the "real" list view it's still visible.

Why do we want to hide those buttons? Asked the R&D accounting team, it should not be allowed to create journals on the fly. You should only be able to create them inside accounting app.

This behavior is not limited to this view but will only be applied locally. The fix can however be applied everywhere where needed.

Before the fix:
-------------------
<img width="700" height="417" alt="image" src="https://github.com/user-attachments/assets/ca11ea13-c38e-40a1-9848-cbc5edc6226e" />
<img width="1507" height="887" alt="image" src="https://github.com/user-attachments/assets/1cde5d3b-3372-4aca-b5d0-2319bd82c1de" />

After the fix:
----------------
<img width="707" height="474" alt="image" src="https://github.com/user-attachments/assets/01dc7b42-43d6-4b18-a12d-54330d51b92b" />
<img width="1457" height="870" alt="image" src="https://github.com/user-attachments/assets/ff387d3f-f59c-47ad-abfe-a2003669db1a" />


opw-6131231

Forward-Port-Of: odoo/enterprise#120379

Currently, an error occurs when a user previews a canceled subscription order.

**Steps to Reproduce:**
 - Install `sale_subscription` module.
 - Go to `Subscriptions` and create a `subscription order` with:
    - a `subscription product`,
    - a `recurring plan`,
    - an `Until` (end date) value.
 - `Cancel` the subscription order.
 - Click `Preview`.

`TypeError: unsupported operand type(s) for +: 'bool' and 'relativedelta'`

When previewing a subscription order, the portal view is rendered. During rendering, the 
subscription portal template is used, which computes tax values and requires calculating the 
next invoice date based on the recurring plan's billing period. However, for canceled 
subscription orders, next_invoice_date is False because it is only set when the order is in 
the sale state. As a result, an error is raised [2].

This commit ensures that only subscription orders in the sale state use the subscription 
portal template. Canceled subscription orders use the default sale order preview, similar 
to orders in the draft and sent states. This is appropriate because canceled subscriptions 
are not correctly displayed in the subscription portal, and they should not attempt to 
render the subscription-specific portal view.

[1]- https://github.com/odoo/enterprise/blob/f833154b61fdb73c24d99462815a55313212b909/sale_subscription/controllers/portal.py#L686-L687

[2]- https://github.com/odoo/enterprise/blob/f833154b61fdb73c24d99462815a55313212b909/sale_subscription/models/sale_order.py#L2172-L2175

sentry-7579114635

**Steps to Reproduce:**
-  Create a Server Action of type 'Webhook Notification'.
- Select a model containing a field that returns a `frozendict`-based structure (e.g. `account.move` → `needed_terms`).
- Add the field to the webhook fields.
- Open the webhook sample payload preview.

**Issue:**
- During sample payload generation:
   - The selected fields are read from a sample record.
   - A selected field returns a structure containing `frozendict` objects.
   - The payload is serialized using `json.dumps()`.
   - JSON serialization fails with:
```text
TypeError: keys must be str, int, float, bool or None, not frozendict
```
  - The webhook sample payload computation crashes and the preview cannot be displayed.

**Root Cause:**
- The webhook sample payload may contain `frozendict` objects returned by selected fields.
- The serializer used for payload generation does not handle such mapping-like objects, causing  `json.dumps()` to fail.

**Solution:**
- Use a serializer that converts mapping-like objects into JSON-compatible structures before serializing the webhook sample payload.

**OPW-6295777**

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#272324
Forward-Port-Of: odoo/odoo#271864

**Steps to reproduce:**
- Install Accounting
- In Accounting settings, activate "Intrastat"

- Create a product with Intrastat info
- Create a bill:
  * Product: [the created Intrastat product]
  * Intrastat Country: [any]
  * Intrastat Transport Mode: [any]
- Confirm the bill
- Make sure that the bill name contains a hyphen character (i.e. "-")
For example, "BILL/2026-06/0001".
Use the "Resequence" action from the bills list view if needed.

- Go to "Accounting / Reporting / Audit Reports / Intrastat Report"
- Expand the line to display the bill name

**Issue:**
The bill name is not fully displayed.
It is cropped right before the hyphen character (i.e. BILL/2026).

**Cause:**
A regex is used to retrieve the bill name from the report line name, but it is only allowing "/" character.

**Solution:**
Just allow "-" character in addition.
No other character is allowed to limit the risk of matching something that should not.

opw-6299854

Forward-Port-Of: odoo/enterprise#120979

### Steps to reproduce the issue:
1. Download Accounting and l10n_it_edi_withholding
2. Switch to IT company
3. Create 2 taxes with a Pension fund type set (in Advanced Options)
4. Create an invoice and set on the same line the 2 taxes created
5. Click on send and print and see the error: Invoices must have at most one Pension Fund tax set per line. (even if it's not true)

### Cause of the issue:
The following function check how many taxes we have per line but this limit is incorrect because it is accepted by the Italian electronic invoicing specifications to have also more than 1 tax. 
https://github.com/odoo/odoo/blob/bd095fe286930acc54d85bdf7f92af15569f5b82/addons/l10n_it_edi/models/account_move.py#L1268-L1273

### Reference documentation:

1. [Art. 10 della Legge n. 183_2011, successivamente integrato dal D.L. n. 1_2012 (art. 9-bis)..pdf](https://github.com/user-attachments/files/29056003/Art.10.della.Legge.n.183_2011.successivamente.integrato.dal.D.L.n.1_2012.art.9-bis.pdf)

2. Following image:
<img width="823" height="580" alt="estrattoEppi" src="https://github.com/user-attachments/assets/e79be16f-651e-467a-84f4-8400185ceea4" />


opw-6264685

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

Forward-Port-Of: odoo/odoo#273040
Forward-Port-Of: odoo/odoo#269456

Currently on the pos payment method form, if you click "Select more" on the journal field, you will see two buttons 'New' & 'Create New'.

Steps to reproduce:
-------------------
* Open any pos payment method
* Select the journal field
* Select "Search more"
> See two creation buttons

Why the fix:
------------
One button is the standard "On search more" button which can be hidden using options such as no_create, no_create_edit, ...

The second button is defined on the list view for journals and since the search more uses the list view it shows the button as well. Currently we can do that with a context key to ensure that on the "real" list view it's still visible.

Why do we want to hide those buttons? Asked the R&D accounting team, it should not be allowed to create journals on the fly. You should only be able to create them inside accounting app.

This behavior is not limited to this view but will only be applied locally. The fix can however be applied everywhere where needed.

Before the fix:
-------------------
<img width="700" height="417" alt="image" src="https://github.com/user-attachments/assets/ca11ea13-c38e-40a1-9848-cbc5edc6226e" />
<img width="1507" height="887" alt="image" src="https://github.com/user-attachments/assets/1cde5d3b-3372-4aca-b5d0-2319bd82c1de" />

After the fix:
----------------
<img width="707" height="474" alt="image" src="https://github.com/user-attachments/assets/01dc7b42-43d6-4b18-a12d-54330d51b92b" />
<img width="1457" height="870" alt="image" src="https://github.com/user-attachments/assets/ff387d3f-f59c-47ad-abfe-a2003669db1a" />


opw-6131231

Forward-Port-Of: odoo/enterprise#120379

## Problem
When multiple Default Prompts are configured for the same AI Agent and
interface key, clicking the "Ask AI" button raises a ValueError.

## Cause
The `_get_composer_from_key_and_model` method searches for composers matching
an interface_key and model, but doesn't limit the results. When multiple
Default Prompts exist for the same agent, the search returns multiple records,
causing a singleton error when accessing `ai_agent_id`.

## Steps to Reproduce

[[Video](https://drive.google.com/file/d/1yMAmX4RuevS0vH07qex2V0fMAiLrtJBg/view?usp=sharing)]
1. Go to AI > Configuration > Default Prompts
2. Create a new Default Prompt with Odoo Agent
3. Click the Ask AI button in the top-right corner
4. Error: ValueError: Expected singleton: ai.agent(2, 1)



## Fix

Replace the two-step search with a single search using an `OR` domain:

- Search both model-specific and generic Default Prompts in one query.
- Order the results with `focused_model_id desc` so model-specific prompts are preferred over generic ones.
- Return only one record using `limit=1`.

This preserves the previous behavior while preventing singleton errors.

---
opw-6323764

**Steps to reproduce:**
* Install the **account_peppol** and **l10n_be** module.
* Switch to BE Company.
* Create and confirm a BE customer invoice.
* Open the "Send & Print" dialog.
* Activate Peppol (register as a Peppol participant) in developer mode and demo mode by clicking on `Why should you use it ?` on the banner in wizard.

**Observed behavior:**
* An Uncaught Promise OwlError trace is thrown on the screen: `TypeError: Cannot use 'in' operator to search for 'toString' in null`.
* The success notification indicating that Peppol was activated fails to appear.

**Cause:**
* Upon successful registration, the `peppol.registration` wizard triggers a client action to display a success notification via `display_notification`.
* The backend Python code explicitly passed `title=None` in the notification parameters, which is serialized to `null` in the JavaScript frontend.
* In previous versions (like 19.2), the `Notification` component's `title` prop validation was defined loosely as `{ type: [String, Boolean, { toString: Function }] }`. OWL did not strictly validate this shape, allowing `null` to pass through without error.
* In 19.3, the prop validation was updated to strictly enforce the object shape: `{ type: [String, Boolean, { type: Object, shape: { toString: Function } }] }`. Because JavaScript evaluates `typeof null` as `"object"`, the OWL validation schema now attempts to verify the shape by evaluating `'toString' in null`. Using the `in` operator on `null` is illegal in JavaScript and immediately crashes the application.

**Fix:**
* Replace `title=None` with `title=False` in the `_action_send_notification` method.
* This translates to `false` in the JavaScript frontend, which seamlessly satisfies the `Boolean` prop type validation for the OWL component and allows the notification to render safely without errors.

opw-6333224

### Steps to reproduce:

- In the settings Enable: Multi-steps Routes, Packages
- Put your warehouse in delivery in 2-steps
- On the Pick operation type in the barcode tab disable: "Allow extra products"
- Create two storable products P1 and P2
- On P2 > On hand > Update Quantity > New
- Create a new line in WH/Output with a package POOK for 1 unit
- Create a new internal transfer for 1 unit of P1 using the pick operation type so that the picking goes WH/Stock -> WH/Output
- Set the quantity of the move to 1 unit and go to the barcode app
- Open the Pick > Scan WH-STOCK > Scan P1 > Scan POOK
#### > An error is raised: This package contains extra products and extra products are not allowed on this operation.
#### Expected behavior:
The package should be set as result package.

### Cause of the issue:

In the `_processPackage`, a check that is done to ensure that the package scan will not add extraproduct to the picking if this operation is not allowed:
https://github.com/odoo/enterprise/blob/5e4c8ecb0c644e21755570ed59cd8f6e9f618c8a/stock_barcode/static/src/models/barcode_picking_model.js#L2024-L2035
Unfortunately, this check is done just before a possible usage of the package as package dest. And, in that case, since we do not try to add any product to the picking the check is irrelevant anyway.

opw-6303969

Forward-Port-Of: odoo/enterprise#121789

When a customer books through Reserve with Google, the createBooking payload carries the booker given_name and family_name next to the email, but the handler passed only the normalized email to _mail_find_partner_from_emails. The new res.partner was therefore created with its name falling back to the email, see
 
https://github.com/odoo/odoo/blob/aa7b5921191a0ff53ef1cc32af99fe458c45c0da/addons/mail/models/res_partner.py#L177

That name then flows into the calendar.event name, the attendee common_name and the contact details, all showing the email instead of the customer name. The module has read neither field since it was added in https://github.com/odoo/enterprise/commit/2e855b910173b56e8501d0ebe9ee6f83ac5845bc.

Build the booker name from given_name and family_name and pass it with the email through formataddr in google_reserve_booking_create, so a newly created partner is named after the customer. A partner matched on an existing email keeps its current name.

Steps to reproduce:
1. Enable Reserve with Google on an appointment type.
2. Book a slot from Google Maps with given name John and family name Doe.
3. Open the created booking and its contact in Odoo.

=> the contact name is the email instead of John Doe

Ticket [link](https://www.odoo.com/odoo/project/49/tasks/6232318)
opw-6232318

Forward-Port-Of: odoo/enterprise#120604

# Setup
Ensure you currently have no activity

# How to reproduce
- Go to any form view with a chatter (e.g. Quotation form view)
- Add 2 activities with a due date of today or before
> Notice there activity counter next to the activity clock icon in the top right should be 2
- Click on the activity clock icon in the top right
> Notifce the activity counter decreases to 1
- Mark as done both To-Do activites

# The problem
The activity counter is negative

# Cause
This issue is due to a desync between the activity counter client side and server side.
When clicking on the activity clock icon, the front-end fetches the mail store data from the
backend, which is why we see the activity counter decrease.

The server computes the activity counter the following way :
https://github.com/odoo/odoo/blob/86b2da224a5c543b279a188928bd47e4d59c2037/addons/mail/models/res_users.py#L457

It searches for up to 1000 activities and group them by the record they are
associated to (e.g. a sale.order). Then, for each of these records, if atleast
one activity is late or for today, increase the counter by 1 :
https://github.com/odoo/odoo/blob/86b2da224a5c543b279a188928bd47e4d59c2037/addons/mail/models/res_users.py#L504-L509

Essentially, server side, we get a single +1 in the activity counter by record, not by activity

On the other hand, client side, we simply add 1 in the activity counter every time a
new activity is created. If an activity is deleted, then we remove 1 :
https://github.com/odoo/odoo/blob/86b2da224a5c543b279a188928bd47e4d59c2037/addons/mail/static/src/core/web/mail_core_web_service.js#L17-L30
https://github.com/odoo/odoo/blob/86b2da224a5c543b279a188928bd47e4d59c2037/addons/mail/models/mail_activity.py#L305-L309

# Proposed solution
Both the client and server side logic were edited fairly recently

Server side :
https://github.com/odoo/odoo/pull/234899

Client side :
https://github.com/odoo/odoo/pull/215880

According to experts, the activity counter should count records, not activities, so we
should fix the client side but properly doing so would introduce too much complexity.
We instead simply prevent the counter from going below 0.

opw-6116821

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

Forward-Port-Of: odoo/odoo#259602

**Steps to reproduce:**
- Install Accounting
- In Accounting settings, activate "Intrastat"

- Create a product with Intrastat info
- Create a bill:
  * Product: [the created Intrastat product]
  * Intrastat Country: [any]
  * Intrastat Transport Mode: [any]
- Confirm the bill
- Make sure that the bill name contains a hyphen character (i.e. "-")
For example, "BILL/2026-06/0001".
Use the "Resequence" action from the bills list view if needed.

- Go to "Accounting / Reporting / Audit Reports / Intrastat Report"
- Expand the line to display the bill name

**Issue:**
The bill name is not fully displayed.
It is cropped right before the hyphen character (i.e. BILL/2026).

**Cause:**
A regex is used to retrieve the bill name from the report line name, but it is only allowing "/" character.

**Solution:**
Just allow "-" character in addition.
No other character is allowed to limit the risk of matching something that should not.

opw-6299854

Forward-Port-Of: odoo/enterprise#120979

**Steps to reproduce:**
- Install Accounting
- In Accounting settings, activate "Intrastat"

- Create a product with Intrastat info
- Create a bill:
  * Product: [the created Intrastat product]
  * Intrastat Country: [any]
  * Intrastat Transport Mode: [any]
- Confirm the bill
- Make sure that the bill name contains a hyphen character (i.e. "-")
For example, "BILL/2026-06/0001".
Use the "Resequence" action from the bills list view if needed.

- Go to "Accounting / Reporting / Audit Reports / Intrastat Report"
- Expand the line to display the bill name

**Issue:**
The bill name is not fully displayed.
It is cropped right before the hyphen character (i.e. BILL/2026).

**Cause:**
A regex is used to retrieve the bill name from the report line name, but it is only allowing "/" character.

**Solution:**
Just allow "-" character in addition.
No other character is allowed to limit the risk of matching something that should not.

opw-6299854

Forward-Port-Of: odoo/enterprise#120979

**Steps to reproduce:**
- Install Accounting
- In Accounting settings, activate "Intrastat"

- Create a product with Intrastat info
- Create a bill:
  * Product: [the created Intrastat product]
  * Intrastat Country: [any]
  * Intrastat Transport Mode: [any]
- Confirm the bill
- Make sure that the bill name contains a hyphen character (i.e. "-")
For example, "BILL/2026-06/0001".
Use the "Resequence" action from the bills list view if needed.

- Go to "Accounting / Reporting / Audit Reports / Intrastat Report"
- Expand the line to display the bill name

**Issue:**
The bill name is not fully displayed.
It is cropped right before the hyphen character (i.e. BILL/2026).

**Cause:**
A regex is used to retrieve the bill name from the report line name, but it is only allowing "/" character.

**Solution:**
Just allow "-" character in addition.
No other character is allowed to limit the risk of matching something that should not.

opw-6299854

Forward-Port-Of: odoo/enterprise#120979

Current behavior:
--
With an active automation rule (base_automation) whose action creates an activity (e.g. a "Time Off Approval" activity) on hr.leave creation, every newly created time off request has a duration of 0 days / 0 hours, regardless of the requested dates.

Expected behavior:
--
The leave duration is computed from the requested dates, unaffected by the presence of an activity-creating automation rule.

Steps to reproduce:
--
- Create an automation rule on hr.leave, trigger "On Creation & Update".
- Add an action that creates an activity (type "Time Off Approval").
- Create any time off request for an employee with a working schedule.
- The request shows a duration of "0 days" (or "0 hours").

Cause of the issue:
--
date_from/date_to and number_of_days/number_of_hours are stored compute fields the duration (number_of_days/number_of_hours) depends on the dates (date_from/date_to). The rule's action creates a mail.activity whose notification renders the leave's display_name. Computing display_name pulls in dashboard_warning_message, which re-enters _compute_date_from_to. Inside that in-progress compute, _compute_duration is evaluated while date_from/date_to are still False in the ORM cache, so _get_durations returns (0, 0). The dates are correct afterwards, but the duration was already computed and stored as 0, and nothing in the create flow re-triggers its compute, so a stale 0 is persisted to the database (it is only recomputed if a dependency such as the request dates or leave type is later modified).

Fix:
--
Once date_from/date_to are settled at the end of _compute_date_from_to, add the duration fields (number_of_days, number_of_hours, duration_display) back to the compute queue so they are recomputed against the correct dates.

opw-6235902

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

**Steps to reproduce:**
- Install Accounting
- In Accounting settings, activate "Intrastat"

- Create a product with Intrastat info
- Create a bill:
  * Product: [the created Intrastat product]
  * Intrastat Country: [any]
  * Intrastat Transport Mode: [any]
- Confirm the bill
- Make sure that the bill name contains a hyphen character (i.e. "-")
For example, "BILL/2026-06/0001".
Use the "Resequence" action from the bills list view if needed.

- Go to "Accounting / Reporting / Audit Reports / Intrastat Report"
- Expand the line to display the bill name

**Issue:**
The bill name is not fully displayed.
It is cropped right before the hyphen character (i.e. BILL/2026).

**Cause:**
A regex is used to retrieve the bill name from the report line name, but it is only allowing "/" character.

**Solution:**
Just allow "-" character in addition.
No other character is allowed to limit the risk of matching something that should not.

opw-6299854

Forward-Port-Of: odoo/enterprise#120979

**Steps to reproduce:**
- Install Accounting
- In Accounting settings, activate "Intrastat"

- Create a product with Intrastat info
- Create a bill:
  * Product: [the created Intrastat product]
  * Intrastat Country: [any]
  * Intrastat Transport Mode: [any]
- Confirm the bill
- Make sure that the bill name contains a hyphen character (i.e. "-")
For example, "BILL/2026-06/0001".
Use the "Resequence" action from the bills list view if needed.

- Go to "Accounting / Reporting / Audit Reports / Intrastat Report"
- Expand the line to display the bill name

**Issue:**
The bill name is not fully displayed.
It is cropped right before the hyphen character (i.e. BILL/2026).

**Cause:**
A regex is used to retrieve the bill name from the report line name, but it is only allowing "/" character.

**Solution:**
Just allow "-" character in addition.
No other character is allowed to limit the risk of matching something that should not.

opw-6299854

Forward-Port-Of: odoo/enterprise#120979

Replaced `useLayoutEffect` with `signal.ref(HTMLDivElement)` + `useEffect` because `useLayoutEffect` is deprecated in OWL3.

The effect drove autofocus on the Property component's root element, triggered both when the DOM element became available and when `env.viewEditorModel.activeNodeXpath` changed. This matches the canonical `signal.ref()` + `useEffect` pattern: converting `useRef('root')` (from `@web/owl2/utils`) to a `signal.ref(HTMLDivElement)` class field makes the element a reactive signal, so `useEffect` auto-subscribes to it and re-runs whenever the element appears. The second dependency is read via `void` inside the callback to force subscription without changing the logic.

The useLayoutEffect refactored in this PR has test coverage — below are some tests that failed when the effect was commented out, and are now passing:
- @web_studio/view_editors/interactive_editor_sidebar/autofocus field label in the sidebar
- @web_studio/view_editors/interactive_editor_sidebar/update sidebar after edition
- WebSuite.test_unit_desktop
see commented-out runbot build: https://runbot.odoo.com/runbot/batch/2602195/build/115250521

## Summary

Part of the incremental OWL3 migration removing `useLayoutEffect` from
`@web/owl2/utils`, which relies on the OWL2 compatibility shim and is
deprecated in OWL3.

The pattern replaced is always the same: `useLayoutEffect` with a static
or stable-ref dependency was used solely to attach DOM event listeners
after mount and clean them up before unmount. In all cases,
`onMounted` + `onWillUnmount` from `@odoo/owl` is the correct native
replacement — the effect runs once, the ref is stable, and no reactive
re-run is needed.

## Commits

- **web_gantt**: `useMultiHover` — replaces per-element `pointerenter`/
  `pointerleave` listeners (re-queried on every patch) with a single
  event delegation pair (`pointerover`/`pointerout`) on the container.
  Simpler and handles dynamic DOM children for free.

- **hr_referral**: Bootstrap carousel `slide.bs.carousel` listener —
  also migrates `carouselRef` from `useRef` to a signal (`t-ref`) and
  `reachedEnd` from a proxy state to a signal. Fixes a latent bug where
  `bind(this)` was called twice (once in `addEventListener`, once in
  `removeEventListener`), making the removal a silent no-op.

- **social_facebook/instagram/linkedin**: Click listeners on comment and
  like buttons queried via `querySelector` — identical structure across
  the three social kanban patches, straightforward one-to-one swap.

Replaced `useLayoutEffect` with `useListener` because `useLayoutEffect` is deprecated in OWL3.

The commented-out effect was a pure event-subscription pattern: its body only called `this.env.bus.addEventListener('AI:OPEN_AI_CHAT', openAiChat)` with a cleanup returning `this.env.bus.removeEventListener`, and its dependency function returned an empty array (register once on mount, unregister on destroy). `useListener(this.env.bus, 'AI:OPEN_AI_CHAT', openAiChat)` is an exact 1:1 replacement — it internally wraps `useEffect` with a null-guard and a `removeEventListener` cleanup, preserving the exact add/remove lifecycle without any dep-array bookkeeping.

The `useLayoutEffect` refactored in this PR has test coverage — below are some tests that failed when the effect was commented out, and are now passing:
- TestAIDraftUI.test_ai_draft_chatter_button (Post install test_ai)
- TestAIDraftUI.test_ai_draft_chatter_button (test_discuss_full_enterprise)
- TestAIDraftUI.test_ai_draft_chatter_button (test_mail_enterprise)
see commented-out runbot build: https://runbot.odoo.com/runbot/batch/2604770/build/115379831

**Steps to reproduce:**
- Install Accounting
- In Accounting settings, activate "Intrastat"

- Create a product with Intrastat info
- Create a bill:
  * Product: [the created Intrastat product]
  * Intrastat Country: [any]
  * Intrastat Transport Mode: [any]
- Confirm the bill
- Make sure that the bill name contains a hyphen character (i.e. "-")
For example, "BILL/2026-06/0001".
Use the "Resequence" action from the bills list view if needed.

- Go to "Accounting / Reporting / Audit Reports / Intrastat Report"
- Expand the line to display the bill name

**Issue:**
The bill name is not fully displayed.
It is cropped right before the hyphen character (i.e. BILL/2026).

**Cause:**
A regex is used to retrieve the bill name from the report line name, but it is only allowing "/" character.

**Solution:**
Just allow "-" character in addition.
No other character is allowed to limit the risk of matching something that should not.

opw-6299854

Forward-Port-Of: odoo/enterprise#120979

Issue:
Voice transcript 'share by email' button would get post the transcript summary to the chatters of all records of a given model.

Steps:
1) install crm and ai
2) activate openai and gemini by saving the api keys inside settings. 3) create 2 crm leads in order
a) lead 1 and lead 2
4) go into lead 1 and in the description then type in '/voice-transcription'. 5) Go into the 'transcription' section of the voice transcription 6) type something and save
7) then click 'start recording'
8) click 'stop recording' - it doesn't need to actually record 9) wait to process
10) click the 'share by email' button
11) check lead 2 for a message created (there shouldnt be one) 12) go back to lead 1 and click the 'share by email' button 13) check lead 2 again and a second message appears. that is becuase it makes a new mail.compose.message with res_ids of a list of multiple crm.lead.id (e

This was fixed in 19.2+ with the pr https://github.com/odoo/enterprise/pull/115978. But it didnt make it in 19.0 and 19.1

Fix:
default_res_ids: model?.config.resIds, -> default_res_ids: [model?.config.resId] take the single record id instead of the list res_ids

opw-6285883

Version: 19.0

`test_sign_request_notification`, `test_gc_removes_orphan_roles_and_dummy_items` ,`test_sign_tour` and `test_sign_tour_without_sign` fail locally when you run them on a db with demo data installed, after doing some manual testing/ operations on it.

- `test_sign_request_notification` builds `completion_mail_to_user` by searching `mail.mail` for any email addressed to the admin's address. If admin had received any other email before this test ran, it got counted too, so the assertion on `len(completion_mail_to_user)` became wrong. We now also filter by subject matching `sign_request.reference`, so it only counts the email this test's own sign request actually generated.

- `test_gc_removes_orphan_roles_and_dummy_items` relies on the helper `_get_signer_and_item_gc_context` to count dummy sign items (page < 0). That helper searched `sign.item` with no domain at all, so any dummy item left behind by a different template got added to `non_active_item_ids` and broke the `len(non_active_item_ids) == 4` check. We now scope that search to `template_id = sign_template.id`, so it only counts items belonging to the template created in the test.

- `sign_tour` had a step targeting `.o-autocomplete--dropdown-item:contains('Administrator')` in the signer autocomplete. After installing demo data the admin user is named `Mitchell Admin`, so the tour failed on databases using that name. Both contain 'Admin', so the trigger now matches on that instead.

taskid- 6329037

Issue Before This PR:

When clearing the Date field in the WIP Accounting Entry wizard, an error was raised during the re-computation of dependent fields. This prevented from temporarily emptying the date field while editing the wizard.

Steps to Reproduce:

- Open the list view of Manufacturing Orders.
- Open the Post WIP Accounting Entry wizard by either:
- Selecting one or more Manufacturing Orders and choosing Actions ,click Post WIP Accounting Entry
- Or, opening a Manufacturing Order form and selecting Post WIP Accounting Entry from the Actions & Reports menu.
- Clear the Date field.
- Observe that an error is raised.

Cause of the Issue:

The compute methods _compute_reversal_date() and _compute_line_ids() assumed that wizard.date was always set. When the Date field was cleared, its value became False, but the compute logic still attempted to compare or use the date, resulting in an error.

With This PR:

The compute methods now verify that wizard.date is set before performing date-dependent computations. This prevents errors when the Date field is temporarily cleared, allowing the wizard to behave correctly during user input.

Issue reference: https://github.com/odoo/odoo/issues/246547

### Steps to reproduce

- Install `sale_timesheet_enterprise`.
- Go to **Tasks → All Tasks**.
- Switch to the **Gantt** view.
- Group by **Sale Order Item** (`sale_line_id`).

### Issue

A traceback is raised when loading the Gantt view with group by `sale_line_id`:

```text
ValueError: Invalid field 'planned_hours' on model 'project.task' for 'planned_hours:sum'
```

### Root cause

The Gantt progress bar computation for the `sale_line_id` grouping performs a `_read_group()` aggregation on the `planned_hours` field of `project.task`.

However, `planned_hours` was renamed to `allocated_hours` during the saas-16.5 migration, so the former field no longer exists on `project.task`. As a result, the aggregation raises a `ValueError`.

Migration reference:
https://github.com/odoo/upgrade/blob/e638c6ce00d9d8936d034ad7130fef51565b9195/migrations/project/saas~16.5.1.2/pre-migrate.py#L10

Issued PR: https://github.com/odoo/enterprise/pull/49685

### Fix

Use `allocated_hours`, the renamed equivalent of `planned_hours`, when computing the Gantt progress bar. This restores the Gantt view when grouping tasks by **Sale Order Item** and prevents the traceback.

Forward-Port-Of: odoo/enterprise#122297

Steps to reproduce:
-------------------------------------------
1. Install the Timesheet module with demo data
2. Go to any FSM task > set allocated hours to 20h
3. Fill the timesheet for the same task for 10h
4. Navigate to FSM > My Tasks > Gantt view

Observation:
-------------------------------------------
Look at the task on the Gantt chart. The shading is barely visible because it covers only 0.5% of the bar, not 50%

Issue:
-------------------------------------------
In the commit
https://github.com/odoo/odoo/pull/137570/changes/4a93d9aee957dd3feb3db0cb69eb3b8f0f4a4683 The progress field computation was changed from storing percentage values (0-100) to storing decimal values (0-1). Specifically, the `_compute_progress_hours` method was modified. This change was made to standardize the progress field storage format, with the understanding that the UI layer would multiply by 100 when displaying the value. While most views (form, list, kanban, etc.) were updated to multiply the progress by 100 for display purposes, the Gantt view's pill progress bar was missed.

Solution:
-------------------------------------------
Overrides the `enrichPill` method to multiply the `_progress` value by 100 before it's passed to the template. This ensures the Gantt pill progress bars display correctly without modifying the core web_gantt module.

Before
---------------------------
<img width="268" height="368" alt="image" src="https://github.com/user-attachments/assets/6d35927f-bd3f-47fc-9101-e2e188d419b8" />


After:
--------------------------
<img width="250" height="371" alt="image" src="https://github.com/user-attachments/assets/fe7133e0-26d1-4c5f-b903-48826fda9488" />


opw-6038983

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.

opw-6332911