### Steps to reproduce:

- In the settings enable Multi-Steps Routes
- Inventory > Configuration > Warehouse Management > Warehouses
- Put you warehouse in delivery in 2 steps
- Create 4 storable products: Kit 1, Kit 2, content, foo
- Create 2 boms of type kit: one for Kit 1 and one for Kit 2, both with:
  - 1 x content
- Create and confirm a sale order with two lines:
  - 1 x Kit 1
  - 1 x Kit 2
> On the associated pick, you can see 2 distinct moves: one per kit
- On the SO add a line for 1 unit of foo and save the SO
#### > On the associated pick both kit moves were merged.

### Cause of the issue:

When you add 1 unit of foo, the `_action_launch_stock_rule` will be called in order to create and confirm the associated stock moves. During the `_action_confirm` of this move a `_merge_moves` will be called to determine if the move can be merged with any other already existing one. However, this merge operation will actually be performed on each of the move present in the "candidate_move_set" which includes all the moves of the already existing picking:
https://github.com/odoo/odoo/blob/8c5ad7621fe8370da4c28d42a51ba06e15ce42ee/addons/stock/models/stock_move.py#L1015-L1027 https://github.com/odoo/odoo/blob/8c5ad7621fe8370da4c28d42a51ba06e15ce42ee/addons/stock/models/stock_move.py#L1011-L1013 This is problematic since the `disting_fields` used as a merging criterion are based solely on the records present in self and not on the candidates on which the merging might be performed: https://github.com/odoo/odoo/blob/8c5ad7621fe8370da4c28d42a51ba06e15ce42ee/addons/stock/models/stock_move.py#L1021 In our case, the reason why the two kit moves where not merged the first time that they were confirmed was because the `bom_line_id` was added to the distinct fields by:
https://github.com/odoo/odoo/blob/8c5ad7621fe8370da4c28d42a51ba06e15ce42ee/addons/mrp/models/stock_move.py#L605-L609 But on the action confirm of the foo move and since this move is not assocaited with a `bom_line_id` of phantom type, it will not and the two kit moves will be considered as good condidates to merge into one an other.

### Fix:

The `distinct_fields` used as a merging criterion should be based on the set of all moves that are  considered to be merged rather than to the moves that we initially wanted to merge.

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

Forward-Port-Of: odoo/odoo#188101

Current behaviour:
---
When you make content of type article in eLearning, then add an animation on scroll on an element,
when you put the article in fullscreen, the animations do not trigger.

Steps to reproduce:
---
1. Go to eLearning
2. Select a course with articles
3. Click on Go to website
4. Go on the article content
5. Open the editor
6. Drag and drop the columns block at the end
7. Select "feature one" and add an animation on scroll
8. After saving, scroll, the animation works
9. Click on "Fullscreen"
10. Scroll again, animation doesn't trigger

Cause of the issue:
---
In website_slide, fullscreen mode, the right scrollable element is not `#wrapwrap`, but `.o_wslide_fs_article_content`

Note:
---
If the animation is not complete, but the page is scrolled at maximum, 
animation intensity can be lowered in the editor panel, so that the animation can finish earlier.

opw-4151770

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

Forward-Port-Of: odoo/odoo#184717

Currently a parse error would arises if the user deletes the saleable product category and try to install POS

To reproduce this issue

1) Install Sale Management without a demo data
2) Delete the Saleable product category
3) Try to install POS

Error:-
```
ParseError: while parsing /home/odoo/src/odoo/18.0/addons/point_of_sale/data/point_of_sale_data.xml:21, somewhere inside
<record id="product_category_pos" model="product.category">
            <field name="parent_id" ref="product.product_category_1"/>
            <field name="name">PoS</field>
        </record>

```

This error is occurring because the user deleted the saleable product category, which leads to the above traceback as the saleable product category is referenced at multiple places to create master data.

https://github.com/odoo/odoo/blob/51296055790f8c6f01dfbbc82ca340756c54cdb3/addons/point_of_sale/data/point_of_sale_data.xml#L16

We can resolve this issue by preventing the user to delete the saleable product category.

sentry-6026143114

Forward-Port-Of: odoo/odoo#188788

In a prior commit [1], a jQuery call was replaced with a vanilla JS implementation, inadvertently introducing an issue where unencoded URLs in background-image caused rendering or validation errors, such as "Invalid property value."

The `style.backgroundImage` property in vanilla JavaScript returns the raw value of the attribute, unlike jQuery's `.css('background-image')`, which automatically encodes URLs.

This fix ensures that URLs extracted are properly encoded using `getComputedStyle`.

Steps to reproduce:

- Install the Blog module.
- Configure your credentials in the Unsplash settings.
- Create a new post within a blog.
- Change the background of the post by searching for "electrical wire" on Unsplash. Select the first image in the results, noting that its filename contains a space.
- Click the "Add" button to set the background image.
- Save the changes.
- Observe that the background image is not applied. Inspect the style attribute of the div, and you will find: background-image: url(/unsplash/hokONTrHIAQ/electrical wire.jpg?unique=6015d8d5); This value is invalid for the background-image property due to the unencoded space in the URL.

[1]: https://github.com/odoo/odoo/commit/f9c9d6c4058086849b7e87174afd7f97d514baad

opw-4233483
opw-4271093

Forward-Port-Of: odoo/odoo#187932

Steps to reproduce the issue:
=============================
- Have 2 p elements where the last one have a link at the end of it
- Copy the 2 lines
- Paste them
- The box around the link is shown which indicates that the cursor is
  inside the link
- Try to add content
- The content is added oustide the link

Origin of the issue:
====================
When the selection have the p element and inside it there is an a
element , currentNode will be the p and not the a, but lastposition
will have the link node which is not padded with zws yet. So we put the
selection without the padding and then it's added which changes the
selection to have anchor node on the end of the ufeff charater inside
the link (`<a>&#xFEFFcontent&#xFEFF[]<a>`) which makes the selection
appears as inside the link but adding content will be after the link.

Solution:
=========
We need to pad the link with zws in case the selection we put is at the
edges of the link.

 ----------------------------------------------- 

Before:
=======
In rtl lang, the cursor gets stuck at the edge of the link using the
arrow keys.

After:
======
No the cursor moves correctly in rtl lang. We need to make `arrowLeft`
as go to next and `arrowRight` as going previous

task-4089193

Forward-Port-Of: odoo/odoo#185707

There are several issues with the company of the folders and the
field `documents_spreadsheet_folder_id` of a company.

To reproduce the issue 01:
1. Create a second company
2. Documents > Configuration > Workspaces, edit "Spreadsheet":
   - Set a company

Step 01, `documents_spreadsheet_folder_id` of the second company is
set to "Spreadsheet" folder thanks to a default value on the field.
But, looking at the DB after the second step, there is an error: both
companies still have the folder "Spreadsheet" defined on
`documents_spreadsheet_folder_id`, but this folder is now specific to
one company. Step 2 should not be possible, a constraint is missing.

To reproduce the issue 02:
1. Repeat above steps 1-2
2. Create a third company

Looking at the DB, there is also an error with the third company: the
default value has been used for it, even though the folder is now
company-specific and can't be used anymore. The default value should
be improved to handle this situation.

Also, it should not be possible to use such record on the field.
Since there is already the attribute `check_company=True` on
`documents_spreadsheet_folder_id`, we could therefore add the attribute
`_check_company_auto` on the model and take advantage of the ORM:
https://github.com/odoo/odoo/blob/f323896028114acb36848b605732797b67fd7da4/odoo/models.py#L614-L618
However, this change would be too invasive on stable, hence the ORM
constraint as alternative.

OPW-4281530

Forward-Port-Of: odoo/enterprise#74189

### Steps to reproduce:

- In the settings: enable multi-steps route
- Inventory > Configuration > Warehouse Management > Routes
- Unarchive MTO
- Create a storable prodcut with MTO, buy routes and a set vendor
- Create and confirm a sale order for 3 units of your product
- Confirm the purchase order and the associated reciept
- Go to the barcode app on you delivery
- set the quantity to 1/3 and leave the barcode app
- Go back to the the delivery
### > only one line 1/1 appears

### Cause of the issue:

The barcode app relies on stock move lines to work properly. These move lines are even in correspondance with the barcode lines. When you update a line in the barcode to be 1/3 and then leave the app, to keep track of the demand, the app split the moves in 2: https://github.com/odoo/enterprise/blob/69338098f5407a01b4ddcb8b18bc82cf9d7cb4d5/stock_barcode/models/stock_move.py#L9-L11 To create the new barcode lines, it is therefore expected that new move lines will be created by this call for the splitted move. which is the purpose of this line:
https://github.com/odoo/enterprise/blob/69338098f5407a01b4ddcb8b18bc82cf9d7cb4d5/stock_barcode/models/stock_move.py#L37 However, this will only work for moves whose procure method is not MTO because mto moves are not confirmed but flaged as waiting and hence not assigned by the `_action_confirm`:
https://github.com/odoo/odoo/blob/e7b269206fa125532c9e3ab6ed2b632198199cd8/addons/stock/models/stock_move.py#L1356-L1362 https://github.com/odoo/odoo/blob/e7b269206fa125532c9e3ab6ed2b632198199cd8/addons/stock/models/stock_move.py#L1380 https://github.com/odoo/odoo/blob/e7b269206fa125532c9e3ab6ed2b632198199cd8/addons/stock/models/stock_move.py#L1418-L1422
As a result no move line will be generated for these splitted mto moves and there will be no stock move line for the barcode to rely on.

opw-4232106
---

Forward-Port-Of: odoo/enterprise#73824
Forward-Port-Of: odoo/enterprise#73773