# How to reproduce
- Create a time off request for a single employee
- Refuse it
- Duplicate it
- Refuse the duplicate
- Try to go back to draft

# The problem
The user is deadlocked and cannot go back to draft because of a client validation on the field employee_ids. The user cannot change that field because it is readonly, so he is stuck.

# Why
When duplicating a hr.leave, employee_id is copied but not employee_ids. Going back to the issue steps, if you look at the Employees field of the duplicate, it is empty. This later cause the issue with the client side validation.

Copying employee_ids when there are multiple employees did not seem like the best idea because a lot of flows relies on employee_id. employee_id is computed as follows :
```py
    def _compute_from_employee_ids(self):
        for holiday in self:
            if len(holiday.employee_ids) == 1:
                holiday.employee_id = holiday.employee_ids[0]._origin
            else:
                holiday.employee_id = False
```
So if we copy multiple employees in employee_ids, employee_id will be null, which might break these flows.

opw-5995398

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

The _compute_cumulated_balance() method performs a query over every
existing move lines to get a dict associating the record id with
the cumulated sum at this point.

When there is a lot of move lines, the result returned by fetchall()
hits the memory limit and the server crashes.

We propose to encapsulate the original query to only return
the result for the account move lines present in self.

Benchmarks
---------------

The following benchmarks were generated with a customization of
the account.move.line list view to display the cumulated_balance
field.

Memory usage during the self.env.cr.execute and the dictionary
population:

|     Operation | Before the fix | After the fix |
|---------------|----------------|---------------|
| populate dict |         1.5 GB |       17.1 MB |
| execute query |         430 MB |        8.3 MB |

100 000 lines were displayed at the same time to get a significant
size.
So the number of records in self is more than 7 000 000 without
the fix and 100 000 with the fix.

Time spent in the _compute_cumulated_balance method:

| No of AML | Before the fix | After the fix |
|-----------|----------------|---------------|
| 7 000 000 |         10.4 s |         6.8 s |

opw-6053720

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