Issue:
======
Collaborator avator disappears after delete

Steps to reproduce the issue:
=============================
- Open to do with 2 browsers
- Write 2 lines
- Put the selection of one in first line
- Put the selection of the other in the second line
- Select all the second line and delete
- The avatar of the collaborator you delete with will disappear from the
  others view.

Origin of the issue:
====================
`selectionchange` on document isn't triggered because :
- The delete doesn't trigger it by default from the browser.
- In `setSelection` in `selection_plugin` we only trigger the
  `selectionchange`  by the line of `setBaseAndExtent` which is not
  triggered when the line is empty because the document selection is the
  `p` element and the given selection from the parameters is also the
  `p` element. In the other case where there is some text left, the
  document have the text node as anchor node while the given params have
  the p element so we change the selection and we trigger
  `selectionchange`.

We need `selectionchange` to be triggered because it calls
`onSelectionChange`  which we use to notify the peers that our selection
is changed and dispath the `oe_history_set_selection` command.

So after this flow, the peer selection isn't changed and the avatar
disappears because `oe_history_step` will call `onExternalHistorySteps`
and then will call `refreshSelection` in the avatar plugin which will
update the position and image of the collaborator. Since the text
element is deleted and we don't have a new selection, `drawPeerAvatar`
will find the node by its id but it's not connected to the dom so it
will exit in the `anchorBlock` if condition.

Solution:
=========
We remove ranges and then we put selection again to force trigger the
selectionchange.

task-4166179w

Currently, when cancelling an order, the notification is not sent to the preparation display.

Steps to reproduce:
-------------------
* Open both restaurant and preparation display
* In the restaurant place an order and send it to the kitchen
* Select Action > Cancel order
> Observation: The cancellation is not sent to the preparation display

Note: If you send a new order or refresh the preparation display then you can see that the order has been cancelled.

Why the fix:
------------
When cancelling order, data looks like this
`{'change': True, 'sound': False, 'category_ids': {}}`. Since `category_ids` is empty, `preparation_displays` will alsos be empty which explains why the preparation display does not receive the notification, it is simply not sent.
https://github.com/odoo/enterprise/blob/42b7b322d6c720de45661e3370397adaf74fe1f4/pos_preparation_display/models/preparation_display_order.py#L29-L40

Since all lines are canceled, we include all the different categories they cover. Now `preparation_displays` is not empty and all the displays it covers will receive a notification.

opw-4322600

In the editor refactoring done in Odoo 18, we slightly changed the structure of the embedded props stored in the anchor node of the embedded views. Now, the view context is nested inside the `viewProps` attribute of the embedded props.

When the user creates a copy of an article using the "Create a Copy" button, we iterate over all the embedded views stored in the article and we update the context of the embedded views. This way if they list the article items of the original article, they must list the article items of the newly created article. This logic was introduced to allow people to start from a fresh and "ready-to-use" article.

As the context has been moved in the embedded props, the check verifying if the embedded view has a context always fails and the references stored in the context are never updated. As a result, the newly created article has embedded views listing the article items of the original article which is not what we want.

To fix the issue, we will read the context from the `viewProps` attribute of the embedded props and remove the last calls to `urllib` we made to encode/decode the embedded view props.

Steps to reproduce:
1. Open Knowledge
2. Create an article
3. Insert an embedded view with `/kanban`, `/card` or `/list`
4. Create a few article items from the embedded view
5. Create a copy of the article you created at step 2 by clicking on the "Create a Copy" button from the kebab menu.

=> The embedded view in the new article lists the article items of the original article and not its own article items.

TO BE: As it was the case before Odoo 18, the embedded views should list the article of the newly created article.

see: https://github.com/odoo/enterprise/pull/42936
see: https://github.com/odoo/enterprise/pull/67083

task-4343222

### Steps to reproduce:

- Enable "Multi-Steps Routes" in the settings
- Inventory > Configuration > Warehouse Management > Warehouses
- Put your warehouse in manufacturing in 2 steps
- Create an MO for a product and add an operation (no need of component)
- Confirm the MO and go to your operation in the shopfloor
- Click on the 3 dots > Add component > add any component
#### >  Back to the MO: No transfer was created from stock to pre-prod

### Cause of the issue:

When you add component from the shopfloor, you will trigger a call of the `add_product` method to create and confirm the raw move associated to the MO:
https://github.com/odoo/enterprise/blob/2e2efe8421b2f85950e50ff102cdabf98d2d91ab/mrp_workorder/wizard/additional_product.py#L36-L37 However, if the `procure_method`` of this move is not set to mto/mtso it will not trigger other rules in order to generate the other transfers

### Note:

A priori, the issue should not be reproducible in 18.0+ as this part of the code was refactored and the issue was fixed by 235047b68e6a24a14e32b94b1d4a15a580dc5ad2

opw-4236272

### Steps to reproduce:
- Create two storable product: Final Product (FP) and Component (COMP)
- Create and confirm an MO for FP with a raw move: 1 x COMP
> The move should be: "not available" since 0 unit of COMP are in Stock
- Go to the barcode module > Operations > Manufacturing
- Remove the MO Ready filter > Click on your MO and then exit barcode
- Go back to the MO in the back end (mrp module)
#### > The raw move has been reserved and is hence marked as available.

### Cause of the issue:

Exiting the barcode will launch an rpc call of the `split_uncompleted_moves` in order to split uncomplete moves in 2 if necessary (for the records to be appropriately set the next time you enter the barcode):
https://github.com/odoo/enterprise/blob/71f979d5bdf88207cb94c83bd6a69633da649d1e/stock_barcode/static/src/models/barcode_picking_model.js#L1327-L1329 https://github.com/odoo/enterprise/blob/71f979d5bdf88207cb94c83bd6a69633da649d1e/stock_barcode/models/stock_move.py#L9-L11 Furthermore, since c29f61fdded2e80d0bb3c06199c6a196feac8076 in case of a production the component move are rather splitted on the move lines to avoid odd split of the component moves on the MO. However, in that case if a unassigned move is splitted, a move line will be generated and associated to that move, which makes it reserved and hence available.

opw-4338827
---

There is currently a problem of synchronization when using multiple tracking displays per pos config.

Steps to reproduce:
-------------------
* Configure 2 Preparation displays, 1 for the category food, the other for
drinks. Link them both to the restaurant
* Open the two preparation displays and their preparation status
* In the restaurant, place an order for 1 food and 1 drink product
* On one of the preparation display mark the food as ready
> Observation: Both status screen will show 'ready'
* Again on the preparation display mark the food as completed
> Observation: The order disappears from both screen.

Refreshing both status screen will not show the same state

Why the fix:
------------
The status screen should be seen as an ORDER status screen.

When placing an order 1 in the restaurant, the status screen should only show it as ready when all the pos preparation display orders linked to that order are ready.

This idea behind this fix is to get the status of the order as they are in the related preparation display and to modify it with regards of other status screen that are linked to the same pos config.

Let's discuss this part:
```python
        for display in other_displays:
            other_display_orders = display._get_pos_orders()
            for order in other_display_orders['notDone']:
                if order in current_display_orders['done']:
                    current_display_orders['done'].remove(order)
                    current_display_orders['notDone'].append(order)
```
`other_display_orders` represent the preparation display orders from other preparation displays.
`current_display_orders` represents the preparation display orders related to the preparation display we just used.

Here we basically ensure that we don't show a preparation order on the status screen as done if there is another preparation order linked to the same order which is not ready.

Scenario:
* `current_display_orders = {'done': ['101', '102'], 'notDone': ['103']} `
* `other_display_orders = {'done': ['101'], 'notDone': ['102', '103']}`
* result -> `current_display_orders = {'done': ['101'], 'notDone': ['103', '102']} `

The fix does not stop here as we also need to consider 2 scenarios:
* 1, we mark a preparation display order as complete in one preparation display.
* 2, we have preparation display orders that are not on the preparation display
but still linked to the same pos config as the status screen opened

In both scenarios, we will have some tracking numbers in `orders` which will not be found in `current_display_orders`.

```python
            for order in other_display_orders['done'] + other_display_orders['notDone']:
                if (
                    order not in current_display_orders['done'] + current_display_orders['notDone']
                    and self.env["pos_preparation_display.order"].search(
                        [('pos_order_id.tracking_number', 'ilike', order)]
                    ).pos_config_id.id in self.pos_config_ids.ids
                ):
                    stage = 'done' if order in orders['done'] else 'notDone'
                    current_display_orders[stage].append(order)
```

This part of the fix will look at all the orders that are not present in `current_display_orders` and if the preparation order belong to a pos order made in the pos config of the current preparation display status then it will be added in the respective stage.

Scenario:
* `current_display_orders = {'done': ['101', '102'], 'notDone': ['103']} `
* `other_display_orders = {'done': ['101'], 'notDone': ['102', '103', '104']}`
* result -> `current_display_orders = {'done': ['101'], 'notDone': ['103', '102', '104']} `

We also apply this logic when loading the status screen for the first time/or refreshing it. We want to see the status of all orders from the set of pos configs.

opw-[4265987](https://www.odoo.com/web#id=4265987&view_type=form&model=project.task)

Steps to reproduce
===================
- Open the resource schedule, and go into day mode.
- Switch to tomorrow, and click new.
- The start date has been changed but not the end date, which is still
  now +duration.
- Which creates a default duration of `-23:00 hours`.

Second issue:
- Open the resource type appointment and then create the booking from the Gantt
  view using the new button.
- We get the wrong appointment type there.

Technical
===========
- Earlier, the stop was calculated based on the current time instead of `start`
  in the default_stop. we set stop datetime inside `onAddClicked` by default to
  start + 1 hour to override the calendar.event's default_stop.

- Earlier, we fell into the condition of fetching only the user appointment when
  we were not providing any resources inside the default_get method, which led to
  having the user-based appointment instead of the resource-based one. Here, we
  added a separate condition to fetch the resource-based when going through the
  action of resource gantt.

After this PR
===================
- This PR addresses the issue and fixes it  by adding the default stop for
  1 hour after the start time and assigning the correct appointment type.

Task-4330924