### To test the flow:

Run the test with debug = True and in the network tab of the browser set throtlling to 3G while the debugger of the first step of the tour is on.

### Steps to reproduce:

1. Create a storable product tracked by SN.
2. Create a delivery order of 1000 units.
3. In Inventory > Operations Types, for the Delivery Orders type, check "Create New" under Lot/Serial Number.
4. Open the barcode app
5. Scan a QR code containing 100 serial numbers.
> makes far too many rpc calls taking ages to resolve in 3G or slow 4G

### Cause of the perf issue:

You will observe that the barcode scanned is treated by the `processBarcode`, generates a list of 100 valid barcodes and that each of these is then processed individually here:
https://github.com/odoo/enterprise/blob/b429e4da99edc73b5cf451c05dba120dde5b3895/stock_barcode/static/src/models/barcode_model.js#L650-L674 However, each individual `this._processBarcode` will lead to two rpc calls, one during the `_getMissingRecord` of the
`prefilled_owner_package_stock_barcode`.

GL Steve <3

opw-4410797

### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/3f48d8b72 [REL] 18.0.20 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/34150250d [FIX] clipboard: cross-sheet cut/paste is broken for tables/cfs [Task: 3905618](https://www.odoo.com/odoo/2328/tasks/3905618)
https://github.com/odoo/o-spreadsheet/commit/4977c01f5 [FIX] css: put `h-100` in o-spreadsheet [Task: 4652289](https://www.odoo.com/odoo/2328/tasks/4652289)
https://github.com/odoo/o-spreadsheet/commit/258cd42f3 [FIX] auto_complete: search pivot value with quotes [Task: 4061068](https://www.odoo.com/odoo/2328/tasks/4061068)
https://github.com/odoo/o-spreadsheet/commit/b694f2c27 [FIX] edition: escape closes the composer [Task: 4646699](https://www.odoo.com/odoo/2328/tasks/4646699)
https://github.com/odoo/o-spreadsheet/commit/a539775a7 [FIX] sheet: autoresize doesn't work on evaluated multiline cell [Task: 4609545](https://www.odoo.com/odoo/2328/tasks/4609545)
https://github.com/odoo/o-spreadsheet/commit/d45269f88 [FIX] Tests: Fix `simulateClick` helper [Task: 4646342](https://www.odoo.com/odoo/2328/tasks/4646342)
https://github.com/odoo/o-spreadsheet/commit/b9127d7d3 [FIX] RemoveDuplicate: fix component initialization [Task: 4646342](https://www.odoo.com/odoo/2328/tasks/4646342)

Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com>
Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>

Issue: Validating deliveries of storable products linked to a subscription will not update the delivered_qty untill the subscription has been invoiced and hence wont allow you to invoice it at all if the invoicing is based on delivered qty.

### Steps to reproduce:

- Create a recurring product which inventory is tacked by quantity and which invoicing policy is based on delivered quantity.
- Put 10 units in stock.
- Create a monthly subscription for 1 unit of that product.
- Confirm the subscription
- Validate the associated delivery
#### > The qty_delivered of the sol is still at 0 and the subscription can't be invoiced.

### Cause of the issue:

Starting from Commit b3ed4416f9b8e37604a9aa38a1f38c3504e22fdf (18.0) we will create the first delivery linked to a subscription rather than waiting for the cron to be triggered. These delivery moves are correctly linked to the related sale order lines of the subscription. However, since future deliveries will also be created and linked to that same sol we need to consider only the outgoing and incoming moves related to the current billing period to determine the qty_delivered. This step is achieved with an override of the `_get_out_going_incoming_moves`: https://github.com/odoo/odoo/blob/a6280b2a5173fad65e62af0ba72cb8721939d709/addons/sale_stock/models/sale_order_line.py#L193-L200 https://github.com/odoo/enterprise/blob/dde492541aa253771f905d0a77650aa35fea0e8c/sale_subscription_stock/models/sale_order_line.py#L27-L34 but this always leads to an empty record set since the order was never invoiced making the`next_invoice_date` and hence the `period_end` coincide with the `start_date` of the order.

opw-4628212

To reproduce the issue:
1. Confirm a SO with partner P
2. Create/Edit an helpdesk team
   - Returns: True
3. Create a ticket for P
4. Open its form view
5. Click on return

Error: a traceback appears "ValueError: Expected singleton: stock.
picking()"

The return button loads the wizard `stock.return.picking`. In this
model, we try to find a related done picking:
https://github.com/odoo/enterprise/blob/7215e4abd904ebdff3bd85c2c2f3002b1f5593b1/helpdesk_stock/wizard/stock_picking_return.py#L24-L31
Which, in the above case, does not exist. Later, we call a method on
that picking:
https://github.com/odoo/odoo/blob/8f527e93de2d64111904f1fcc5813e8b8ea0e4ba/addons/stock/wizard/stock_picking_return.py#L100-L104
Where `_can_return` is a `ensure_one` method, hence the error.

The return button is only displayed in some conditions:
https://github.com/odoo/enterprise/blob/3d8bb40fcad00068e12f21b623390c959d3fd19c/helpdesk_stock/views/helpdesk_ticket_views.xml#L35
Here is the problem: `has_partner_picking` can be `True` if we find
some related SOL, which is useless, the only thing that matters are
the related pickings.

OPW-4591280

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

Steps
-----
1. Create an event with an attendee limit of 1;
2. publish the event;
3. add a ticket to you cart;
4. go through checkout until your reach the payment page;
5. open a incognito window or different browser;
6. add same ticket to cart;
7. go to the payment step;
8. click "Pay now" and wait for confirmation;
9. go to previous window, and click "Pay now".

Issue
-----
The payment gets confirmed, but you land on an internal server error due to a lack of available seats for the event.

Cause
-----
Commit ffc9026361beb added a check before payment to ensure the tickets still had seats available. The event itself however can have a separate seat limit that isn't currently being checked.

Solution
--------
Add a check on the event's seat availability to `_validate_transaction_for_order`.

Also, in case there's a lack of seats, display the correct number of lacking seats for the order instead of `-available_seats`.

opw-4453539

Forward-Port-Of: odoo/odoo#201906
Forward-Port-Of: odoo/odoo#200400

### Steps to reproduce:

- Create a storable product tracked by serial number available from the pos and with a set pos category.
- Open a pos session and click on your product.
> A dialog openns for you to register serial numbers.
- Edit a first SN: SN001 and press enter
> A new line can now be set to create a second one.
- Edit a second SN: SN002 and press enter
- Confirm the dialog
#### > The quantity displayed on teh POS order line is 1 rather than 2.

### Cause of the issue:

Clicking on the product card from the pos will trigger a call of the `AddProductToCurrentOrder` that will add a quantity of the product set via the options:
https://github.com/odoo/odoo/blob/6197233ef1611ddd974cfdb06ae2568e4af369de/addons/point_of_sale/static/src/app/store/pos_store.js#L1965-L1978 However, the `getAddProductOptions` call sets a quantity to add of 1 no matter if you added multiple or even removed multiple registered SN. https://github.com/odoo/odoo/blob/6197233ef1611ddd974cfdb06ae2568e4af369de/addons/point_of_sale/static/src/app/store/models.js#L180 On the other hand, since at the moment of this call we do not have the info of the lines that were removed in the dialog it is not possible to always provide the correct (possibly negative) quantity to add to the line for the qty to be correctly handledby the posorder line. However, just as when you edit the line dirrectly this can be achieved by updating the quantity based on the relevant lots present on the line: https://github.com/odoo/odoo/blob/6197233ef1611ddd974cfdb06ae2568e4af369de/addons/point_of_sale/static/src/app/store/models.js#L570-L572

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

Forward-Port-Of: odoo/odoo#201550
Forward-Port-Of: odoo/odoo#199127

In point of sale it is possible to manage several orders at the same time and, whenever an order is paid, all orders will be synchronized with the backend. This causes an issue with loyalty rewards that are granted even for orders not yet completed.

Steps to reproduce:
- Have a Loyalty Program configured as follows:
  - Program Type: Loyalty Card
  - Grant 1 point per $ spent
- Create a Loyalty card for [Partner]
- Open POS Session
- Add a [Partner] as customer
- Add product
- Leaving the order as it is, create a new order
- Add just a product
- Validate & Pay the second order

Issue: Loyalty points will be added to [Partner] Card, as if the order was actually paid

This occurs because we don't check that the order has been actually paid before processing rewards

opw-4538040

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

In Point of sale promotion program may be auto applied to the order
whenever the conditions of the promotions are satisfied.
However, a promo 'buy x get y' is auto applied inconsistently when
comparing the output with the reward button (or applying the promotion on a sales
order)

Steps to reproduce:
- Have a promo program like follows:
  - Program Type: Buy X Get Y
  - Condition:
    - Minimum quantity: 2
    - Grant: 1 credit per order
    - Product: [PRODUCT]
  - Reward:
    - In exchange of: 1 credit
    - Product: [PRODUCT]
    - Quantity rewarded: 1
- Open POS Session
- Add 2x [Product]

Issue:
- "Free" [PRODUCT] line is added to the order with negative price

So the customer will buy 1 [PRODUCT] and get 2 that is not what we want
with the promo program
If we delete the reward line, click on reward button and choose again
the same promo we get the correct behavior:
- Exisitng [PRODUCT] line quantity raised to 3
- "Free" [PRODUCT] line added to the order with negative price

opw-4563825

Forward-Port-Of: odoo/odoo#199752

Before this PR, the `bus subscription is refreshed when channel is joined` test was sometimes failing.

Since [1], opening a thread *always* result in a bus subscription being issued (the channel is added to the bus channels as a string). This is not required: bus subscriptions are based on user's channels (see `ir_websocket@_build_bus_channel_list`). When a new channel is added, the client subscribes again (see `toggleBusSubscription`).

Channels should only be added explictly when a channel the user is not a member of is opened. This addition causes a race condition between `toggleBusSubscription` and the explicit addition of the channel, resulting in a non deterministic behavior.

This PR fixes this issue: channel is only added when required, which is not the case in this test thus solving the issue.

fixes runbot-106895

[1]: https://github.com/odoo/odoo/pull/174473

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#202226
Forward-Port-Of: odoo/odoo#202009

Steps to reproduce
==================

- Install hr_timesheets
- Go to Timesheets > All Timesheets
- Use the week scale
- Scroll to the bottom => Take note of the last record (e.g.: Walter Horton)
- Now use a mobile viewport
- Make sure the week scale is still applied
- Scroll to the bottom => The last record is not the same one as the desktop view

Cause of the issue
==================

The grid view uses a virtual scroll hook in order to not have to many dom nodes in memory at the same time. For this to work, we need a consistent row height.

On mobile, when grouping by x amount of fields, they are stacked on top of each other. When grouping by more than 2 fields, there wasn't enough space to display them all.

![image](https://github.com/user-attachments/assets/08f604e3-ae3e-4a73-86d9-41bd4dbfaf9a)

The `grid-template-rows` was set to auto on mobile in order to accomodate that case.

Using auto means we no longer have a consistent row height.

Solution
========

We restore the `gridTemplateRows` and allocate extra space when needed.

![image](https://github.com/user-attachments/assets/5254d7a6-0e32-4321-8e46-abcf0609dcaa)


opw-4208357

Forward-Port-Of: odoo/enterprise#81617
Forward-Port-Of: odoo/enterprise#80476

### Issue:

The current qty forecast of rental orders does not rely on incoming and outgoing quantities that could happen prior to the location period and would hence modify the availability forecast.

### Steps to reproduce:

- Create a storable product that can be rented put 100 units in stock.
- Create a sale order for 10 units of that product, confirm and confirm the delivery planned for next week.
- Create a rental order for 5 units of that product for a period ulterior to the delivery.
- Look at the forecast rentable quantity.
#### > It should be 90 but it is 100.

### Cause of the issue:

The forcasted quantity of a rental order line is based on the `qty_available` of the product:
https://github.com/odoo/enterprise/blob/01b6a70348ffa11a9ead2558571b1ccfa1dd3cbb/sale_stock_renting/models/sale_order_line.py#L115-L129 https://github.com/odoo/odoo/blob/3264e3399918b9627693e78d684ac9ac4ad3bd7d/addons/stock/models/product.py#L31-L43 However, this quantity does not take the incoming and outgoing moves that are planned to happend prior or during the location. In case the renting period starts at an ultarior date than today, it should rather be based on the `virtual_available` quantity of the product:
https://github.com/odoo/odoo/blob/3264e3399918b9627693e78d684ac9ac4ad3bd7d/addons/stock/models/product.py#L44-L55 (note that since we need to take into account each of the incoming and outgoing moves that could happen prior to the location, the `from_date` context key needs to be set to today).

opw-4552760

Forward-Port-Of: odoo/enterprise#81532
Forward-Port-Of: odoo/enterprise#81127

Description of the issue this commit addresses:

A traceback is raised when importing some .cod files for bank transactions because the server tries to create a date element with a string that doesn't match the expected format.

---

Steps to reproduce:

1. Install l10n_be_coda
2. Go to the accounting dashboard and import the file `02-minimal-test.cod` from the linked ticket.
3. A traceback is raised

---

Desired behavior after this commit is merged:

The file import doesn't raise a traceback.

---

Note on the fix:

The issue happened because in `_get_coda_file_statement()`, the date is expected to be on the index range 115-120 but the the decoding of the file in `_parse_bank_statement_file()` transformed a "€" in "Ôé¼" which moved the date to indexes 117-122. This wrong translation of encoding happened because cp850 was used - which doesn't support currency symbols - instead of utf_8 because the latter was stopped by a non matching regex that was missing the currency symbols.

This commits includes currency symbols in the validating regex so that the most appropriate encoding is validated as often as possible.

---

opw-4546281

Forward-Port-Of: odoo/enterprise#81329