This commit:
1. Removes useless btn-group around "New" button
2. Removes useless borders in the cog dropdown
3. Makes the edit modal buttons more consistent with the rest of the modals
4. Fixes an alignment problem when the loading indicator is displayed
5. Fixes an alignment problem between cog and count

| - | 2 | 3 | 4 | 5 |
|--------|--------|--------|--------|--------|
| before | ![image](https://github.com/odoo/enterprise/assets/8558351/fcd965f4-89c8-4031-a81f-6dcb1fbfb9b6) | ![image](https://github.com/odoo/enterprise/assets/8558351/0dbd0a57-62dc-4171-94af-8db6e8ac88b8) | ![Screenshot 2023-11-07 at 11 37 30](https://github.com/odoo/enterprise/assets/110090660/4c2a450c-313c-4d17-b318-dccca8926e83) | ![Screenshot 2023-11-07 at 11 39 49](https://github.com/odoo/enterprise/assets/110090660/8e0fe921-d75a-484f-bb1b-766090d56d88) |
| after | <img width="227" alt="Screenshot 2024-04-04 at 11 04 49" src="https://github.com/odoo/enterprise/assets/110090660/bc264ad0-28b7-44a4-b4ae-29cf03b3f33a"> | <img width="231" alt="Screenshot 2024-04-04 at 11 03 54" src="https://github.com/odoo/enterprise/assets/110090660/891554fa-7ac8-4f3b-9566-5340e98522ea"> | <img width="196" alt="Screenshot 2024-04-04 at 11 02 57" src="https://github.com/odoo/enterprise/assets/110090660/7479740b-80fd-47af-95e4-8b4fbc8228d9">| <img width="198" alt="Screenshot 2024-04-04 at 11 03 25" src="https://github.com/odoo/enterprise/assets/110090660/32229f8e-16d9-487b-845d-704f7a07e63e">|


task-3580143

## Pull Request HOOT (PRHOOT) - part 27

Part 1: https://github.com/odoo/odoo/pull/152930
Part 2: https://github.com/odoo/odoo/pull/153018
Part 3: https://github.com/odoo/odoo/pull/153023
Part 4: https://github.com/odoo/odoo/pull/153203
Part 5: https://github.com/odoo/odoo/pull/153425
Part 6: https://github.com/odoo/odoo/pull/153700
Part 7: https://github.com/odoo/odoo/pull/154054
Part 8: https://github.com/odoo/odoo/pull/154579
Part 9: https://github.com/odoo/odoo/pull/155073
Part 10: https://github.com/odoo/odoo/pull/155639
Part 11: https://github.com/odoo/odoo/pull/156255 / https://github.com/odoo/enterprise/pull/58135
Part 12: https://github.com/odoo/odoo/pull/156869
Part 13: https://github.com/odoo/odoo/pull/158384 / https://github.com/odoo/enterprise/pull/59019
Part 14: https://github.com/odoo/odoo/pull/158916
Part 15: https://github.com/odoo/odoo/pull/160292 / https://github.com/odoo/enterprise/pull/59971
Part 15.5: https://github.com/odoo/odoo/pull/166463
Part 16: https://github.com/odoo/odoo/pull/166311
Part 17: https://github.com/odoo/odoo/pull/168328
Part 18: https://github.com/odoo/odoo/pull/171004 / https://github.com/odoo/enterprise/pull/65657
Part 19: https://github.com/odoo/odoo/pull/171242 / https://github.com/odoo/enterprise/pull/65767
Part 20: https://github.com/odoo/odoo/pull/173332 / https://github.com/odoo/enterprise/pull/66895
Part 21: https://github.com/odoo/odoo/pull/174337
Part 22: https://github.com/odoo/odoo/pull/176777 / https://github.com/odoo/enterprise/pull/68721
Part 23: https://github.com/odoo/odoo/pull/179660 / https://github.com/odoo/enterprise/pull/69728
Part 24: https://github.com/odoo/odoo/pull/181971
Part 25: https://github.com/odoo/odoo/pull/183358
Part 26: https://github.com/odoo/odoo/pull/186403 / https://github.com/odoo/enterprise/pull/73361

Enterprise: https://github.com/odoo/enterprise/pull/74093

This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details.

Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk.

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

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

Issue:
When printing PDF reports, long account names cause the report to overflow out of the page.

Steps to reproduce:
- Install the accounting app
- Enable "Analytic Accounting" in the settings
- Create one (or more) analytic account(s) with very long names
- Open either "Balance Sheet" or "Profit and Loss" reporting
- Do an "Analytic Group By" with the created account(s)
- Print the PDF

Cause:
The default style in the associated scss file does not use wrapping.
https://github.com/odoo/enterprise/blob/bf6c64b8fd5591f271e9b0f18f40d205a64cd5bd/account_reports/static/src/scss/account_pdf_export_template.scss#L41

Solution:
Override the default style by using the "o_overflow_name" class. This is the class already used for handling overflow in the tables' content lines. This gives a more readable result than just editing the "white-space" field (see below for comparison).


The proposed solution gives the following result:
![image](https://github.com/user-attachments/assets/265d96f4-fd8b-4152-a56a-07dcad662ef0)

As opposed to just editing to "white-space: wrap;"
![image](https://github.com/user-attachments/assets/b2a5a704-5ea2-4ef1-b2aa-48f778575b3a)

Ticket:
opw-4277596

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

Versions
--------
- 17.0+

Community: https://github.com/odoo/odoo/pull/188440

>[!important]
>All functional changes are made in `sale`, this PR simply adds a test.

Steps
-----
1. Have a confirmed subscription;
2. go to subscription management in portal;
3. set or change payment method.

Issue
-----
The following email is sent:
> A payment [...] amounting $ 0.00 for [...] has been confirmed.

Cause
-----
The `_reconcile_after_done` override in `sale` sends a payment succeeded mail for any sale order linked to a transaction that wasn't confirmed by that transaction.

It currently assumes all the transactions in `self` are actual payment operations, as any `validation` gets filtered out in `_finalize_post_processing`, before `_reconcile_after_done` is called[^1].

This assumption no longer holds with `sale_subscription` installed, which also calls `_reconcile_after_done` on validation transactions to manage payment tokens linked to subscriptions[^2].

Solution
--------
Filter out `validation` transactions before calling `_send_payment_succeeded_for_order_mail` on linked orders.

opw-4169491

[^1]: https://github.com/odoo/odoo/blob/12de68d342b/addons/payment/models/payment_transaction.py#L998-L1003
[^2]: https://github.com/odoo/enterprise/blob/bbd1be56538/sale_subscription/models/payment_transaction.py#L135-L144

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