The crm_iap_mine module extended the crm tour, by adding steps to introduce the lead generation feature. These steps were inserted in the middle of the tour, which caused the tour to backtrack and loop on itself.

Why?
For the tour to wait for the next step, we specify the selectors it should look for. In this case, because the modal redirects to the same page (with an updated domain), we cannot specify a selector that would be unique to the new page -> the target is found before the redirect -> after the redirect happens, the tour backtracks to try and recover, causing the loop.

Moving the steps to the end of the tour fixes the issue.

The disadvantage of this is that no the last step of the tour is not deterministic - it can fail if the user selects a combination of countries and industries which have no valid leads (Antarctica...) or if the user doesn't have enough IAP credits. In this case, the 'Congrats' rainbowman is shown even if the generation failed.

Task-5386684

Forward-Port-Of: odoo/odoo#259960
Forward-Port-Of: odoo/odoo#249733

**Version:**
---------
- saas-19.2+

**Steps to reproduce:**
------------------------
* Install the *Inventory (stock)* module.
* Create a *storable product* with tracking enabled.
* Update the on-hand quantity to *5 units*.
* Navigate to *Inventory > Operations > Scrap* and create a new scrap
  record.
* Select the created product and set a quantity *greater than the
  available on-hand quantity (e.g. 6)*.
* Click on *Confirm*.
* An *insufficient quantity* wizard opens.
  * Click on *Discard*.
  * Then click again on *Confirm* in the wizard.

**Issue:**
---------
* A traceback occurs with the following error:
  `ValueError: Expected singleton: stock.move()`

**Cause:**
----------
* When clicking *Confirm*, button the insufficient quantity wizard is opened
  with a `scrap_move_id`.
https://github.com/odoo/odoo/blob/3206cd9bc0af33b047138fc6666a14f8d11da785/addons/stock/models/stock_move.py#L2747
https://github.com/odoo/odoo/blob/3206cd9bc0af33b047138fc6666a14f8d11da785/addons/stock/models/stock_move.py#L2742
* Clicking *Discard* button triggers `action_cancel`, which unlinks the
  associated `scrap_move_id`.
https://github.com/odoo/odoo/blob/3206cd9bc0af33b047138fc6666a14f8d11da785/addons/stock/wizard/stock_warn_insufficient_qty.py#L48-L49
* However, the wizard remains open, and clicking *Confirm* again
  triggers `action_done`, which calls:
https://github.com/odoo/odoo/blob/3206cd9bc0af33b047138fc6666a14f8d11da785/addons/stock/wizard/stock_warn_insufficient_qty.py#L46
* At this point, `scrap_move_id` no longer exists, leading to the
  singleton error.

- Before saas-19.2
This behavior was previously handled in:
https://github.com/odoo/odoo/commit/c361c3778ef4755b4760039a4fd8f9ed88294b64

Later in this commit https://github.com/odoo/odoo/commit/1c7d80a10b5d7db1c4163166bf52b3f3c77044ba
the condition was removed during refactoring, causing the scrap move is to be unlinked in all flows.

**Fix:**
------
* Add a context key to ensure that the scrap move is only unlinked
  during the `action_scrap` flow, preventing access to a deleted
  `scrap_move_id`.

---

opw-6128188


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

When a user attempts to download a POS order receipt for an Indian company, a traceback is raised.

Steps to reproduce the error:
- Install ``l10n_in_pos`` module with demo data
- Switch to IN Company
- Open a PoS Session > Create an order > Payment > Validate
- Navigate to the backend
- Go to Orders > Open the created order > Download Receipt

Traceback:
```
QWebError: Error while rendering the template:
KeyError: 'l10n_in_hsn_code'
Template: point_of_sale.pos_orderline_receipt_information
```

https://github.com/odoo/odoo/blob/9fe02a4585ce139c2ea20e9d282bc92f37b7cad7/addons/point_of_sale/controllers/main.py#L24
Here, ``order_receipt_generate_image`` method is called using the current request
environment. As a result, the active company becomes the user's current company
instead of the POS order’s company.
Because of this mismatch, the condition that adds ``l10n_in_hsn_code`` to the
POS data fields (based on the company’s fiscal country) is not satisfied at [1].
Consequently, the field is missing from the receipt line data at [2],
and the template raises a KeyError when trying to access it.

[1]: https://github.com/odoo/odoo/blob/9fe02a4585ce139c2ea20e9d282bc92f37b7cad7/addons/l10n_in_pos/models/pos_order_line.py#L21-L24

[2]: https://github.com/odoo/odoo/blob/9fe02a4585ce139c2ea20e9d282bc92f37b7cad7/addons/point_of_sale/receipt/pos_order_receipt.py#L76

sentry-7417101015

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

Since https://github.com/odoo/odoo/pull/166843, we remove the odoo links entirely from the spreadsheet on `freeze and share`. While it is true that the link is not usable from a public page (and that we'd somehow leak internal views information in the links), cells with links benefit from a specific style that is not hardcoded on the cell but rather computed based on their content.
By removing the links from teh cells altogether, the greenish link style is lost on those cells and we actually rely on that style for our dashboards layout.

To preserve the intension of https://github.com/odoo/odoo/pull/166843, we introduce a new type of links `neutralized` which allows the cell to be recognized as a link (and benefit from the style) while disabling their behaviour (no click).

Task-6063301

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#260250
Forward-Port-Of: odoo/odoo#256357

Issue 1:
---
Capturing/voiding transaction is failing with the error:
`The payment provider rejected the request. Original pspReference required for this operation`

Steps to reproduce:
1- Setup Adyen payment provider.
2- Enable `Capture amount manually`.
3- Create a SO and confirm.
4- Generate a payment link and pay.
5- In SO, capture the full amount.

Cause:
---
After https://github.com/odoo/odoo/commit/efc2788dfccd13ee6feb309430ff57e49664ff97, in the payment `_void()`/`_capture()`, a child tx is created.
However the child tx is missing the `provider_reference` required to send the payment provider.


Issue 2:
---
The child tx created for capture/void is always remains in draft state.

Cause:
---
This is reproduced after https://github.com/odoo/odoo/commit/efc2788dfccd13ee6feb309430ff57e49664ff97 which we create a child tx in capture/void. But in `_search_by_reference` which is called by webhook to find the tx, we are returning the source tx. As a result only the state of the source tx is changed.

opw-6120846
opw-6120071

Forward-Port-Of: odoo/odoo#259223

An issue is observed when two categories share the same name but are assigned to different websites, and a product is linked to both categories.

Steps to Reproduce:
====================
1. Create two Ecommerce categories with the same name, one assigned to Website 1 and the other to Website 2.
2. Create a product and assign both categories to it.
3. On Website 1, navigate to the product page and click the category breadcrumb → works correctly
4. On Website 2, navigate to the same product page and click the category breadcrumb → **404 error**

Cause:
======
In `_prepare_product_values`, when no category is passed in the URL, the fallback was:
https://github.com/odoo/odoo/blob/a253cff9039fcf729a9922b119acad5ec7c7a0bd/addons/website_sale/controllers/main.py#L802

This blindly picks the **first** category from the product's public categories without checking which website it belongs to. If the first category (by ID order) belongs to Website 1, it gets used even when the user is browsing Website 2.
The breadcrumb then generates a slug pointing to Website 1's category. When clicked on Website 2, `can_access_from_current_website()` fails for that category, resulting in a 404.

Solution:
=========
Filter `public_categ_ids` through `can_access_from_current_website()` before selecting the first one.

opw-6070191

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

Forward-Port-Of: odoo/odoo#258336

Before this commit, Call Menu did not have the "Picture-in-Picture" action. This is unfortunate because this is one of the most valuable action to have it available there, as a frequent usage of Discuss is to join a call, switch to another conversation or chatter, and then wanting to keep an overlay of the call.

Without the "Picture-in-Picture" in Call Menu, this forces user to access the Discuss conversation again and then click on "Picture-in-Picture" there, when clicking on the call menu would be faster.

This commit adds the "Picture-in-Picture" action in the call menu to ease using this feature.

Also fixes an issue where "Fullscreen" and "Picture-in-Picture" actions have reduced opacity in the Call Menu. This comes from opacity hover effect that should be limited to their inline visual in the Call view but was mistakenly also present in the dropdown.

Before / After
<img width="440" height="369" alt="Screenshot 2026-04-17 at 14 15 58" src="https://github.com/user-attachments/assets/2accb779-28f5-4930-a101-db5e52b029b7" />

Forward-Port-Of: odoo/odoo#259866

**Steps to reproduce:**
- Install the `accountant` and `purchase` modules.
- Create and confirm a Purchase Order (with 1 quantity).
- Create a vendor bill using `auto-complete` from the PO, 
  set the quantity to 1, and `confirm` it.
- Navigate to Accounting > Review > `Billed Not Received`.
- Change the `date` from the top left.
- Select a record and click `Create Accrual Entries`.

**Error:**
`TypeError: '<=' not supported between instances of 'datetime.date' and 'str'`

**Root cause:**
At [1], the `accrual_entry_date` is set in the context as a `string`. 
Later, at [2], this value is retrieved from the context and used 
directly in a comparison with `ivl.date`, which is a `datetime.date`.

**Fix:**
This commit converts `accrual_entry_date` to a `datetime.date` object at [2], 
allowing users to create accrual entries without errors.

[1]:
https://github.com/odoo/enterprise/blob/3ab460a935c6caf013202ec6be1c3708178c8d7d/account_reports/static/src/views/accrual_list_controller.js#L61-L76

[2]:
https://github.com/odoo/odoo/blob/7e17c788babc2715e85456467db9172bb0b8e42d/addons/account/wizard/accrued_orders.py#L166-L188

opw-6110907

Forward-Port-Of: odoo/odoo#259047

Since https://github.com/odoo/odoo/pull/166843, we remove the odoo links entirely from the spreadsheet on `freeze and share`. While it is true that the link is not usable from a public page (and that we'd somehow leak internal views information in the links), cells with links benefit from a specific style that is not hardcoded on the cell but rather computed based on their content.
By removing the links from teh cells altogether, the greenish link style is lost on those cells and we actually rely on that style for our dashboards layout.

To preserve the intension of https://github.com/odoo/odoo/pull/166843, we introduce a new type of links `neutralized` which allows the cell to be recognized as a link (and benefit from the style) while disabling their behaviour (no click).

Task-6063301

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#260250
Forward-Port-Of: odoo/odoo#256357

Issue 1:
---
Capturing/voiding transaction is failing with the error:
`The payment provider rejected the request. Original pspReference required for this operation`

Steps to reproduce:
1- Setup Adyen payment provider.
2- Enable `Capture amount manually`.
3- Create a SO and confirm.
4- Generate a payment link and pay.
5- In SO, capture the full amount.

Cause:
---
After https://github.com/odoo/odoo/commit/efc2788dfccd13ee6feb309430ff57e49664ff97, in the payment `_void()`/`_capture()`, a child tx is created.
However the child tx is missing the `provider_reference` required to send the payment provider.


Issue 2:
---
The child tx created for capture/void is always remains in draft state.

Cause:
---
This is reproduced after https://github.com/odoo/odoo/commit/efc2788dfccd13ee6feb309430ff57e49664ff97 which we create a child tx in capture/void. But in `_search_by_reference` which is called by webhook to find the tx, we are returning the source tx. As a result only the state of the source tx is changed.

opw-6120846
opw-6120071

Forward-Port-Of: odoo/odoo#259223

Currently, Intrastat transaction values are not set when creating 
a vendor bill using the `Auto-complete` feature based on a previously 
created vendor bill for an `EU customer`.

**Steps to reproduce:**
- Install `account_intrastat` and `l10n_de` modules and switch to a `DE company`.
- Create a vendor bill for an `EU partner`, add a product, and set an 
  `Intrastat` (enable from the optional column if needed).
- `Confirm` the bill and note its number.
- Create a new vendor bill for the `same partner`.
- Use the `Auto-complete` feature by selecting the previous bill.
- Check the invoice lines.

**Observation:**
The `Intrastat` is missing from the generated invoice lines.

**Root Cause:**
- On using `Auto-Complete`, `_onchange_invoice_vendor_bill` at [1] 
  copies invoice lines using `copy_data()`.

- However, in `account_intrastat`, `copy_data()` at [2] removes 
 `intrastat_transaction_id`.

**Fix:**
This commit ensures that `Intrastat` is properly set when creating a 
vendor bill using the auto-complete feature based on a previously 
created vendor bill for an EU customer.

[1]:
https://github.com/odoo/odoo/blob/07b72963c665f2fe5b741b8815f2351129a2271c/addons/account/models/account_move.py#L1808-L1820

[2]:
https://github.com/odoo/enterprise/blob/4da85b58a28837379e4839327ea914bd6aa70bf9/account_intrastat/models/account_move.py#L77-L83

opw-5936869

Forward-Port-Of: odoo/enterprise#112857

Backport of https://github.com/odoo/odoo/pull/251769

Before this commit, Discuss code may crash with the following error:

```js
TypeError: Cannot read properties of undefined (reading '_raw')
```

This happens because delete operations in JS models could lead to inconsistent state of record lists. Deletion of a record is done internally as follow:

```js
const index = recordList.indexOf(record);
recordList.splice(index, 1);
```

This is done that way as to reuse custom methods of `RecordList`, especially the `splice()` that is used by many methods that mutate the record list. Internal code of the custom `splice` method does `slice()`, which is used to retrieve some records without mutating the record list.

In practice, these `.slice()` were accidentally mutating the list, because they invoke the `Proxy.getter` of the `RecordList`, and when the list is flagged for `computeOnNeed` / `sortOnNeed`, invoking this `Proxy.getter` would mistakenly enable the `computeInNeed` / `sortInNeed` flags and thus mutate the list, e.g. with a sort, which may change the order of items and mess up the `index` computed in `indexOf()` step.

This is what might happen with deletion of any item in record list. For example, let's have `menuThreads` that have this value:

```js
menuThread = ["thread_1", "thread_2", "thread_3"];
```

With the removal of `thread_2`, the `.indexOf()` is `1`, but due to `.slice()` triggering the sort, the list was changed to:

```js
menuThread = ["thread_2", "thread_1", "thread_3"];
```

... And it instead removed `thread_1` but kept `thread_2` in list. This introduce 2 problems:
- `thread_1` is mistakenly removed from relation when it shouldn't
- `thread_2` is kept, but since this is a local id with no actual record in store, `recordList[index]` would return `undefined` as there's no existing record matching this local id.

This commit fixes the issue by improving internal code of record list methods to avoid accidental triggering of lazy re-compute and re-sort. The accidental re-compute and re-sort come from invoking non-implemented array methods on the proxy of record, such as:

- `recordProxy.at()`
- `recordProxy.slice()`

These methods were just used meant to retrieve records from the record list, and they did so by using accessing through `recordProxy`. This approach has the benefit to look good as this is exactly the same as the external API, but it has the unintended side-effect of the re-compute / re-sort of lazy fields. Instead of using these methods, records are retrieved with:

- raw access to get local ids in relation
- convert local ids to raw records through raw access in `store.recordByLocalId`

This approach, while uglier, has the benefit to not accidentally trigger the re-compute / re-sort.

Task-4793779

Forward-Port-Of: odoo/odoo#260109

Steps to reproduce the bug:
- Create a service product "P1":
  - In the Purchase tab:
    - Vendor: Azure Interior
    - Subcontract Service: True
  - UoM: dozen
  - Purchase UoM: unit

- Create a sales order with 1 dozen of P1
  - Confirm -> a purchase order with 12 units of P1 is generated
- Confirm the purchase order
- Go back to the sales order:
  - Update the quantity from 1 to 2 dozen

Problem:
A new purchase order is generated, but with 144 units instead of 12
units. The quantity difference between the old SO quantity and the new
one is computed twice in the purchase order line UoM, in both
`_purchase_increase_ordered_qty` and `_purchase_service_prepare_line_values`:
https://github.com/odoo/odoo/blob/17.0/addons/sale_purchase/models/sale_order_line.py#L186

Solution:
The `quantity` parameter must be expressed in the SO line UoM, as
described in the documentation of the function `_purchase_service_prepare_line_values`.

https://github.com/odoo/odoo/blob/17.0/addons/sale_purchase/models/sale_order_line.py#L178

opw-6049106

Forward-Port-Of: odoo/odoo#257637
Forward-Port-Of: odoo/odoo#255478

Users who do not have the "write" access on `product.template` and `product.product` cannot print product labels and product variant labels

Steps to reproduce:
1. Install Sales
2. Log in as Marc Demo
3. In Sales > Products > Products, open a product and click Print Labels from the cogwheel menu
4. An access error is raised Same issue happens for Product Variants

Issue:
https://github.com/odoo/odoo/commit/95ace0a694eaf83329b50e6b89f774f0c59fec5e removed Products-related rights from the `base.group_user`. This made a difference in terms of access rights, as the `IrActionServe.run` method checks for the "write" access by calling
`_can_execute_action_on_records`:
https://github.com/odoo/odoo/blob/d15685304f479541879fabd55ea1cae4252a2a90/odoo/addons/base/models/ir_actions.py#L1230-L1239

Solution:
Add `group_user` to the `group_ids` of the relevant actions to prevent the check on the "write" access from being performed
This is a backport of https://github.com/odoo/odoo/commit/6c2c353f30db05579f5e8b7a6752ec2d1ae365b2

opw-6111333

Currently, Intrastat transaction values are not set when creating 
a vendor bill using the `Auto-complete` feature based on a previously 
created vendor bill for an `EU customer`.

**Steps to reproduce:**
- Install `account_intrastat` and `l10n_de` modules and switch to a `DE company`.
- Create a vendor bill for an `EU partner`, add a product, and set an 
  `Intrastat` (enable from the optional column if needed).
- `Confirm` the bill and note its number.
- Create a new vendor bill for the `same partner`.
- Use the `Auto-complete` feature by selecting the previous bill.
- Check the invoice lines.

**Observation:**
The `Intrastat` is missing from the generated invoice lines.

**Root Cause:**
- On using `Auto-Complete`, `_onchange_invoice_vendor_bill` at [1] 
  copies invoice lines using `copy_data()`.

- However, in `account_intrastat`, `copy_data()` at [2] removes 
 `intrastat_transaction_id`.

**Fix:**
This commit ensures that `Intrastat` is properly set when creating a 
vendor bill using the auto-complete feature based on a previously 
created vendor bill for an EU customer.

[1]:
https://github.com/odoo/odoo/blob/07b72963c665f2fe5b741b8815f2351129a2271c/addons/account/models/account_move.py#L1808-L1820

[2]:
https://github.com/odoo/enterprise/blob/4da85b58a28837379e4839327ea914bd6aa70bf9/account_intrastat/models/account_move.py#L77-L83

opw-5936869

Forward-Port-Of: odoo/enterprise#112857

Currently, an error occurs when user tries to create a csv for w2 form with no end date defined.

Steps to replicate:
- Install `l10n_us_hr_payroll`.
- Open Payroll > Reporting > W2 Report.
- Click `New` > Remove value from `End Date` and click Generate.

Error:
```
  File '/home/odoo/odoo19/enterprise/l10n_us_hr_payroll/models/l10n_us_w2.py', line 249, in action_generate_csv
    self.csv_filename = f'form_w2_{self.date_end.year or date.today().year}.csv'
                                   ^^^^^^^^^^^^^^^^^^
AttributeError: 'bool' object has no attribute 'year'
```

Cause:
- As the user did not give any value for `End Date`, False was passed and when the execution flow reached [here] `self.end_date` is False and attempting to access `self.end_date.year` results in this error.

Solution:
- If we do not receive the `self.end_date` while generating the CSV, we will use the current year to generate the CSV file name.

[here]: https://github.com/odoo/enterprise/blob/01be8d6e9384bcb340559847d529b4887e073519/l10n_us_hr_payroll/models/l10n_us_w2.py#L248

No ID

Forward-Port-Of: odoo/enterprise#113408

Steps to reproduce:
1. Install `documents`
2. Create a portal user and share a document folder with edit access
3. Log in as the portal user on a mobile device
4. Try to upload a document inside the shared folder

Issue:
- After selecting a file from the file picker, the document is not uploaded.

Cause:
- On mobile in the portal flow, Upload is triggered from a nested dropdown (inside New) inside the adaptive control-panel dropdown (bottom sheet). By default, DropdownItem uses closingMode="all", so tapping Upload closes parent dropdowns immediately. That unmounts the hidden <input type="file"> before the OS file picker returns. When the user comes back, the input no longer exists, so change never fires and upload does not start.
- Admin/internal users do not hit the same nested adaptive-dropdown path in this view

Solution:
- Set closingMode="'none'" on the Upload DropdownItem so the menu stays mounted while the native picker is open. After a file is selected and onFileInputChange starts upload, close the bottom sheet programmatically with: `window.dispatchEvent(new Event("popstate"))`

opw-5937105

FIX 1:  industry_fsm_sale: set delivery address on project customer]
-----------------------
**Steps to reproduce:**
- Create a product:
   - Product Type: Service
   - Service Tracking: Create on Order (project)
   -  Project Template: FSM type project template
- Confirm a sale order with this product
- Check the generated project customer

**Issue:**
   The customer's delivery address is not set on the generated project.

**Fix:**
  Set the delivery address as the project customer when creating the project.

[FIX] industry_fsm_sale: remove default sale line in fsm projects
------------
**Steps to reproduce:**
   - Install industry_fsm_sale
   - Create a project template of fsm type
   - Create a sale order (service-type product)
   - Confirm the sale order
   - Create a project and select the fsm-type project template
   - Create the project

**Issue:**
  - SQL constraint is triggered, preventing project creation.

**Fix:**
  - If the project template is of fsm type, remove the default sale line from the context.

task-5074893

Currently, Intrastat transaction values are not set when creating 
a vendor bill using the `Auto-complete` feature based on a previously 
created vendor bill for an `EU customer`.

**Steps to reproduce:**
- Install `account_intrastat` and `l10n_de` modules and switch to a `DE company`.
- Create a vendor bill for an `EU partner`, add a product, and set an 
  `Intrastat` (enable from the optional column if needed).
- `Confirm` the bill and note its number.
- Create a new vendor bill for the `same partner`.
- Use the `Auto-complete` feature by selecting the previous bill.
- Check the invoice lines.

**Observation:**
The `Intrastat` is missing from the generated invoice lines.

**Root Cause:**
- On using `Auto-Complete`, `_onchange_invoice_vendor_bill` at [1] 
  copies invoice lines using `copy_data()`.

- However, in `account_intrastat`, `copy_data()` at [2] removes 
 `intrastat_transaction_id`.

**Fix:**
This commit ensures that `Intrastat` is properly set when creating a 
vendor bill using the auto-complete feature based on a previously 
created vendor bill for an EU customer.

[1]:
https://github.com/odoo/odoo/blob/07b72963c665f2fe5b741b8815f2351129a2271c/addons/account/models/account_move.py#L1808-L1820

[2]:
https://github.com/odoo/enterprise/blob/4da85b58a28837379e4839327ea914bd6aa70bf9/account_intrastat/models/account_move.py#L77-L83

opw-5936869

Forward-Port-Of: odoo/enterprise#112857

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

Currently, an error occurs if a user changes the product in a BoM, updates the manufacturing order (MO) based on that BoM, and then attempts to unbuild the order.

## Steps to replicate:
- Install Manufacturing without demo data
- Settings > Enable Variants
- Create the following products:
    - Car with (Red and Blue Color attributes)
    - Red Paint
- Create a BoM for Car and product variant set to Red Car and have Red paint as the component.
- Create and Confirm manufacturing order for Red Car
- Click on Bill of Material > Set Paint required to 2 > Save
- Set product variant in BoM to Blue and save again.
- Go back to MO > Update BoM > Produce All
- Unbuild qty 1 > Confirm

## Observed Behavior:
ZeroDivisionError: float division by zero

## Root cause:
This issue occurs because the Update BoM button remains visible on the Manufacturing Order (MO) even after the product has been changed.

The problem starts when a user initially updates the required paint quantity from 1 to 2. At that point, the function [1] marks the BoM as outdated for all linked MOs, which makes the Update BoM button appear. However, if the user later changes the product template or variant, the BoM is still considered outdated. This incorrectly allows the user to update the MO using a BoM that no longer matches the selected product.

**Why this causes a traceback when unbuilding?**

When the user clicks Update BoM, it triggers the `action_update_bom function` [2], which calls `_link_bom`. This process recomputes several fields to align the MO with the updated BoM. One of the methods triggered during this recomputation is `_compute_move_finished_ids` [3]. Since the production is already confirmed, the logic skips adding the production to `production_with_move_finished_ids_to_unlink_ids`, meaning no new finished moves are created for that updated product.

As a result, although the MO is updated, its finished product (`move_finished_ids.product_id`) still refers to the original product (for example, Red Car), instead of the newly selected one.

Later, when the user attempts to unbuild the product, the `action_unbuild` function [4] is executed, which calls `_generate_consume_moves` [5] During this step, the system tries to compute a factor that depends on `unbuild.mo_id.quantity_produced`.

However, because the finished moves still reference the old product and do not match the MO’s current product, the computed total becomes zero at [6] This leads to a division by zero error at [5], which ultimately causes the traceback.

[1]:
https://github.com/odoo/odoo/blob/444de5354dcd70e9160a985486317a8912d53a84/addons/mrp/models/mrp_bom.py#L432-L447 [2]:
https://github.com/odoo/odoo/blob/444de5354dcd70e9160a985486317a8912d53a84/addons/mrp/models/mrp_production.py#L1044-L1048 [3]:
https://github.com/odoo/odoo/blob/444de5354dcd70e9160a985486317a8912d53a84/addons/mrp/models/mrp_production.py#L771-L800 
[4]:
https://github.com/odoo/odoo/blob/97b60952d59a57aba12b048cb4da4f41d85d2ea2/addons/mrp/models/mrp_unbuild.py#L153-L164
[5]:
https://github.com/odoo/odoo/blob/444de5354dcd70e9160a985486317a8912d53a84/addons/mrp/models/mrp_unbuild.py#L225-L232 [6]:
https://github.com/odoo/odoo/blob/444de5354dcd70e9160a985486317a8912d53a84/addons/mrp/models/mrp_production.py#L641-L647

## Solution:
This change prevents users from updating a Bill of Materials (BoM) after the main product or its template has been modified, by ensuring the BoM is not marked as outdated.

This approach make sense because, once a manufacturing order (MO) is confirmed, all raw materials are physically reserved before production begins. While it makes sense to update BoM components in response to an Engineering Change Order (ECO) or last-minute specification changes, it does not make sense to allow changes to the final product itself on existing confirmed MOs. Doing so could lead to operational errors, since materials have already been procured and reserved for a specific product.

This fix ensures that if the product variant or product template is updated in the BoM, users cannot update the MO based on that BoM. This also prevents potential divide-by-zero errors when attempting to unbuild the product in the MO.

Reference commit which also suggests this behavior for the `Update BoM` button: [commit](https://github.com/odoo/odoo/commit/d7392829c769ef50456a7bc93d4482072b329463#:~:text=An%20exception%20however%3A%20if%20the%20MO%20is%20confirmed%20and%20the%20BoM%27s%20product%20was%0Achanged%2C%20the%20MO%20shouldn%27t%20have%20the%20%22Update%20BoM%22%20button%20displayed.%0AOtherwise%2C%20it%20would%20change%20the%20finished%20product%20of%20a%20confirmed%20MO.)

opw-6044754