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

Since the Accounting Returns refactor https://github.com/odoo/enterprise/pull/81569 the “Returns” button and the Return-Period date mode only appear when the current `account.report` carries at least one return type (i.e., `self.return_type_ids` is non-empty). Localization modules (e.g., PE) attach `account.return.type` to the filing (root) VAT report, while ledger/variant reports (e.g., VAT Report (RCE Purchase 8.5) (PE)) are presentation variants and usually do not repeat that configuration.

As a result, opening a variant report yields:
No Returns button, because _init_options_buttons() checks only `self.return_type_ids`. No Return Period chip and wrong/no return-period boundaries, because the date initializers also check/use only `self.return_type_ids`. Even if the button is shown by a downstream customization, `action_open_returns() would still open an empty list because it filters on `self.return_type_ids.ids`.

Why the issue happens:
Variant reports (like RCE 8.5) have `self.root_report_id` pointing to their root VAT report, which does carry `return_type_ids`. But the in odoo we  checks/uses only the current report’s`return_type_ids`, which is empty on variants. Hence: missing Returns button, missing Return Period, and wrong/empty return filtering.

Fix:
Adopt the reporting engine’s existing “inherit from root when on a variant” pattern and its already used elsewhere for `variants_source_id`, custom handlers ...

Introduce a tiny helper: Prefer explicit types on the current report if present; otherwise fall back to the root’s types. Replace direct uses of self.return_type_ids by the effective types in: _init_options_buttons: show Returns on variants too. _init_options_return_periodicity: enable Return Period on variants when the root has exactly one type. _init_options_date(return-period branch):  compute correct boundaries from effective types. _get_shifted_dates_period(return-period branch): shift using effective types. _get_date_bounds_info(..., 'previous_return_period'): validate count and compute previous period from effective types. action_open_returns: filter the list view by the types of variants if present or the root  instead if the variant’s empty.

Before this commit:
On VAT Report (RCE Purchase 8.5) (PE): no Returns button is shown when you are in variant.

After this commit:
Returns button appears.
Return Period mode works
Open Returns action lists the correct returns (filtered by the effective type).

Steps to reproduce:
Install PE_reporting module
make sure dev move is on
Accounting -> Reporting -> tax reports
Click on reports and switch from `Report: Group by: Account > Tax` to `RCE Purchase 8.4` Return Button is not there any more :(

[opw-4973204](https://www.odoo.com/odoo/my-tasks/4973204)

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

### Issue:
When a kit BoM has `product_qty` > 1 (e.g. 12 Kit X = 12 Comp A + 12 Comp B), the SO line cost after confirmation is multiplied by the batch size. Selling 1 Kit X shows a cost of 360 instead of 30.

### Cause:
The method `_compute_average_price` uses `bom.explode(self, 1)`, which returns raw BoM line quantities for one full batch. It accumulates the total batch cost but returns it without dividing by `bom.product_qty`.

### Steps to Reproduce:
- Costing Method = AVCO, Inventory Valuation = Automated
- Comp A (cost 10), Comp B (cost 20), Kit X (cost 0)
- Kit BoM: 12 Kit X = 12 x Comp A + 12 x Comp B
- Create and confirm a SO for 1 x Kit X
- Expected SO line cost: 30
- Actual SO line cost: 360

Solution:
This fix mirrors the normalization already done in `_compute_bom_price`, which correctly divides by `bom.product_qty` and converts UoMs.

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

Forward-Port-Of: odoo/odoo#253948
Forward-Port-Of: odoo/odoo#253406

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

project_template_id is a company dependent field. When creating a project, it is called without the proper company context set up. When confirming an SO through the portal, the order's env is setup without a company and `.with_user(SUPERUSER_ID)`, making future company_dependent variables use OdooBot's company.

Following examples earlier in the function, call `.with_company` while accessing project_template_id.

Steps to reproduce:
1. Install Sales and Project
2. Create second company
3. Create Customer with portal access, under created company
4. Create service product with different projects for each company
5. Create sales order with customer and service product, send to customer
6. Login as customer on portal, accept and sign SO a. Should stall, RPC Error in console

Ticket: opw-6082772

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