**Steps to reproduce:**
* Install  `stock` module.
* Go to  Settings and enable: 
     * Storage Locations (Warehouse).
     * Batch, Wave & Cluster Transfers.
* Create a Product and set its on-hand quantity to 60.
* Go to Inventory → Configuration → Operation Types and create a new operation type:
     * Set Type of Operation to Internal Transfer.
     * In the Barcode App tab, enable Group batch lines.
* Go to Inventory → Operations → Internal Transfers and create a new transfer:
     * Select the newly created Operation Type.
     * Add the created Product with quantity 4.4.
     * Mark the transfer as To Do.
* Create another Internal Transfer with the same configuration:
     * Select the same Operation Type.
     * Add the same Product with quantity 48.8.
     * Mark the transfer as To Do.
* Open the Internal Transfers list view.
* Select both created transfers.
* Click Action → Add to Wave Transfer.
     * Choose A new Wave Transfer and confirm.
* In the popup, select both transfers and add them to the wave.
* Open the Barcode application.
* Open the created operation and select the Batch on the right side
to open the wave transfer in the barcode interface.

**Observed behavior:**
- The grouped line quantity is displayed as 53.99999996 instead of
the expected value(53.2).

**Cause:**
- When the Barcode app loads data,` _createState()` is executed,
which calls `groupLines()`.
- Inside this method, quantities are aggregated using standard
JavaScript floating-point addition:

https://github.com/odoo/enterprise/blob/08d0a7f480046bb489ca69e7b3535e99cb20eee5/stock_barcode_picking_batch/static/src/models/barcode_picking_batch_model.js#L204-L205

- Since JavaScript stores numbers as binary floating-point values,
decimals like 4.4 and 48.8 cannot be represented exactly.
Repeated additions accumulate precision errors, producing results
like 53.99999996 instead of 53.2.

**Fix:**
- Aggregate quantities using `formatFloat` with the barcode precision
before converting them back to floats

- `formatFloat` rounds the value according to the configured precision
of the barcode model, ensuring the intermediate result is normalized
after each addition. Converting the formatted value back with
`parseFloat` guarantees the stored number respects the expected
decimal precision and prevents floating-point accumulation errors.

---
opw-5932329

Forward-Port-Of: odoo/enterprise#113927
Forward-Port-Of: odoo/enterprise#110241

Currently an error occurs when user refreshes on Generic tax report.

**Steps to produce:**
* Install accountant (with demo)
* Search Tax Returns > Enter values and `Apply`>Generic Tax report
* Refresh the page and error will occur on the terminal.

**Error:**
`ValueError: Expected singleton: account.report()`

**Cause:**
After a refresh, the ORM call [1] is executed. However, since the report view has changed, `reportId` becomes `undefined`, as it no longer exists in the context.

This issue did not occur in `18.2` because, prior to refactor [2] , the report view remained unchanged after a refresh.
As a result, it consistently received the same parameters.

**Solution:**
* Use the stored action `account_reports.action_account_report_gt` 
  similarly to the issue solved in [3]

[1]:
https://github.com/odoo/enterprise/blob/1094409426eb8c7d24f385dc28e0011a75b2019d/account_reports/static/src/components/account_report/controller.js#L183-L193

[2]: https://github.com/odoo-dev/enterprise/commit/ff7a5f529c9984c2bfd7950136bcf8c0ecae3964

[3]: https://github.com/odoo/enterprise/pull/47896
**Sentry-6612074136**

This error occurs when a user attempts to discard changes after manually syncing currency rates. The issue arises because the `res.config.settings` record was not initialized beforehand.

This error occurs `saas-18.3` onwards after the following commit ff7a5f529c9984c2bfd7950136bcf8c0ecae3964

The error occurs on line:
https://github.com/odoo/enterprise/blob/79a15ac661d6fb8b6afc9ef791f5fae9349ae2a2/currency_rate_live/models/res_config_settings.py#L1375

**Steps to replicate**
* Install `accountant`
* Enable Multi-Currency
* Settings > Select Journal Under Tax periodicity (Do not save!)
* Automatic Currency Rates > Next Run > Update now (reload button) > Discard

`ValueError: Expected singleton: res.config.settings()`

**Solution:**
* Set Journal in `res_config_settings` similar to `saas-18.2` which initialized the `res_config_settings` model as shown below: https://github.com/odoo/enterprise/blob/fd82255b6a597627ff04d4cf65f8238ba8b921c7/accountant/__init__.py#L23-L24

**Sentry-6740605775**

Currently, a ParseError is arising when the user upgrades the `hr_payroll` module after deleting the `Worker` in Structure Types.

Steps to Reproduce:
---
- Install `Payroll` module (without demo data).
- Payroll > Configuration > Structures > Delete `Worker Pay`
- Configuration > Structure Types > Delete 'Worker'
- Now upgrade the `Payroll` module

Traceback:
---
```py
ValueError: External ID not found in the system: hr.structure_type_worker

ParseError: while parsing /home/odoo/src/enterprise/saas-18.4/hr_payroll/data/hr_payroll_structure_data.xml:15, somewhere inside <record id="structure_worker_001" model="hr.payroll.structure">
            <field name="name">Worker Pay</field>
            <field name="type_id" ref="hr.structure_type_worker"/>
```

At [1], we reference the ID of the `Worker` record. After deletion, that record no longer exists, which results in a ParseError.

Solution:
---
Users are restricted from deleting the Structure Type.

[1]- https://github.com/odoo/enterprise/blob/92ad37e25deeb1f9f1f24f85b085b575e70c0a5d/hr_payroll/data/hr_payroll_structure_data.xml#L15-L20

sentry-6377659355

Sometimes, when adding a new shift (with an employee) in a gantt view that uses `PlanningEmployeeAvatar`, we can have twice the same employee.

It can happens on groupby/filtering/reordering/etc.. An exemple could be to have a gantt view with Shift1 User1 we have:
```
+--------------+
| Shift1 User1 |
+--------------+
```
Add another shift (Shift 2) with User2.
We'll have:
```
+--------------+
| Shift1 User1 |
+--------------+
| Shift2 User1 |
+--------------+
```
instead of
```
+--------------+
| Shift1 User1 |
+--------------+
| Shift2 User2 |
+--------------+
```

Because in this case, when we add Shift2, the view will append Shift1 and after it will rename the old Shift1 to Shift2, but in our case, the renaming is not done and so, it retains the old value.

This is because in the `PlanningAvatarAction` setup we use `setupDisplayName`. The purpose of this function is to split the displayName contained in a `span` into two `span` elements using a `useEffect`. For example, `<span>Employee (Department)</span>` will be replaced by
```html
<span>Employee</span><span class="..">(Department)</span>
```
in order to apply a “muted” style to the department. But to do this, the function will replace the original first span and overwrite it,
```xml
<span t-if=“props.displayName” class="text-truncate flex-grow-1" t-esc=“props.displayName”/>
```
since it contains a `t-esc`, which allows Owl to remain “subscribed” to this element and notify components when to update if the displayName ever changes; however, by overwriting it, Owl is no longer aware of the change.
Therefore, whenever a component's value changes
(in our case, Shift1 becomes Shift2), it is never updated.

In fact, manually manipulating the DOM in a useEffect, as `setupDisplayName` does, is not a good solution.

To fix this flow, this commit adds a new `t-key` attribute to the original span with a value of `this.props.displayName`, which ensures that when the `t-key` changes value because `displayName` is updated, Owl will recognize that a change has occurred and will re-render.

opw-6128168

When a menu item URL contains a space and has no leading slash (e.g.,
"some url"), creating a page from its 404 screen does not link the menu
to the newly created page. The menu keeps pointing to a 404.


**Steps to reproduce**:
1. Create a menu item with a URL containing spaces and no leading slash
   (e.g., "some url").
2. Click the menu item -> a 404 page is displayed (expected).
3. Click "Create Page" -> the page is created and saved.
4. Click the menu item again -> it still returns a 404 (unexpected).


**Issue**:
During page creation, the path is slugified (e.g., "some url" ->
"/some-url"). The controller then tries to link the menu to the new page
by setting `page_id`. However, `pagenew()` only searches for menu URLs
with a leading slash, so a menu saved as "some url" is not found when
searching for "/some url". As a result, `page_id` is never set, and
`_clean_url()` keeps resolving the menu to "/some url" instead of the
page's actual URL "/some-url".

Menus without spaces (e.g., "mypage") have the same issue where
`page_id` is not set, but since `_clean_url()` prepends "/" and renders
"/mypage", which matches the new page URL, the menu still resolves
correctly.


**Fix**:
Match both URL formats (with and without leading slash) when linking a
menu to a newly created page.

Additionally, a warning is now shown in the menu editor when a URL
contains spaces, since spaces are slugified during page creation,
which could cause confusion. (Note: this is only a warning - URLs with
spaces are still allowed.)

task-[5095646](https://www.odoo.com/odoo/project/974/tasks/5095646)

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

Forward-Port-Of: odoo/odoo#260726
Forward-Port-Of: odoo/odoo#248967