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