Stock quants are not meant to be duplicated. This commit ensures that it is not possible to copy such records.

opw-4035690

(cherry picked from commit 044210f6c7c4e539b8ebd41082c737e8bc91fd4e)

---

In PR https://github.com/odoo/odoo/pull/172376 it was decided to not completely forbid quant duplication due to potential third party modules that could potentially use this feature.

However, we see an increment of customer with an incorrect quantity in past history, or a discrepancy in valuation and accounting because of this error.
Unfortunately, it is incredibly easy to duplicate the quants by mistake, for example by miss-clicking when trying to export or update the inventory qty to 0 ...

![image](https://github.com/user-attachments/assets/ef74c5fa-16f4-4532-a5ac-686c32056f29)

Hence, even if it breaks some third party modules, it is imperative to prevent further quants duplication.

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

Forward-Port-Of: odoo/odoo#177796
Forward-Port-Of: odoo/odoo#177584

**Description of the issue/feature this PR addresses:**
There is a bug with traceback on accounting dashboard when is clicked "Checks to print" on bank journal with more than one outgoing payment with "Checks" Payment Method.

**Steps to reproduce:**

1) With a database in v16 onwards, install the account_check_printing module.

2) Go to "Accounting / Configuration / Accounting / Journals" and create a new journal bank with more than one outgoing payment with "Checks" Payment Method.

3) Go to "Accounting / Vendor / Payments" and create a new payment with journal created on step 1 and "Checks" payment method and confirm.

4) Go to "Accounting" and on "Accounting dashboard" click on "Check to print" on Journal created on step 1 and then a bug with traceback is raised.

**Current behavior before PR:**
There is a bug with traceback on accounting dashboard when is clicked "Checks to print" on bank journal with more than one outgoing payment with "Checks" Payment Method.

**Desired behavior after PR is merged:**
There is not a bug with traceback on accounting dashboard when is clicked "Checks to print" on bank journal with more than one outgoing payment with "Checks" Payment Method.

**Video/Screenshot link:**
https://drive.google.com/file/d/1r6A3uMkFv2nIDZ1HYJLgj6e18pNH1P67/view

Ticket Adhoc side: 75606
Task latam: 1217

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

Forward-Port-Of: odoo/odoo#168383

To reproduce the bug, follow these steps:

1. Create a new time off type.
2. Create a new accrual plan.
3. Set the "Accrued Gain Time" field to “At the start of the accrual period.”
4. Create a new milestone with a cap.
5. Create a new allocation set its type to accrual then link it to our accrual plan.
6. Set the start date in the past so that the accrued days reach the cap.
7. Create a new leave in the past related to the allocation.
8. Check your balance for a future date in the Time Off app.

Normally, with accrual allocation, we should see the allocation increase. The problem here is that in the future, the
allocation decreases.

This issue arises due to the way the `leaves_taken` field is computed.

https://github.com/odoo/odoo/blob/08a4b9d78addeefde24b189f0066540e0dcee4c4/addons/hr_holidays/models/hr_leave_allocation.py#L215-L220

The value is retrieved from a default dictionary, which is processed based on existing records in the database. When we
attempt to fetch the value using a new instance that only exists in memory, the key returns the default value of 0.

Additionally, if we modify step 7 to set the leave in the future, the accrual value caps out at a level below the
intended maximum. In some cases, if the data-fetching function is called with the same parameters consecutively, we
receive different outputs.

These issues arise because the new record persists as a cache. When we retrieve a new record with the same origin as a
previous call, we receive the previously processed data. This also leads to a problem with recursion in the function
`_get_future_leaves_on`. This commit addresses and resolves these issues.

opw-4040882

Forward-Port-Of: odoo/odoo#174354

Since the rule refactor, additional byproducts are not considered in the post production picking. The problem is when we add a new byproduct, the backend do not add the warehouse_id on the stock move, and without a warehouse id, it was impossible to find a stock rule for it. Now, with the correct warehouse and stock rule, the stock move is added on the transfers.

Testing steps:
---------------------
- go to configuration > settings > enable Multi-step routes 
- go to configuration > warehouses and enable either 2 or 3 step manufacture
- go to configuration > enable byproducts
- create a BOM with some components/byproducts
- create a MO with the BOM above, confirm it.
Now, we can see the 'transfers' button with 2 transfers, one by the components and another one for the final products and the byproducts.
- add a new byproduct with some produced quantity.

Problem:
-------------
No picking for the new byproduct when clicking on the transfer button

Expected behaviour:
------------------------------
The byproduct should be in the list

task: 3982566

Forward-Port-Of: odoo/odoo#170280

- Have an one2may or a many2many on a setting (with some data in them);
- Edit/toggle any setting;
- Click on an action button or navigate to another view;
- On the "Unsaved changes" dialog, select "Discard".

Before this commit, the `discard` function of the relational model,
didn't take into account the initial commands, and replace the x2many
with an empty list of commands.
The issue is that the settings need to be saved (after discarding the
changes) when leaving, throws an action's button. This is done, to
create a res_id, that is most of the time mandatory to perform the
action (see [1])
 So if the `discard` function, empty the x2many, the setting will be
 modified, and the x2many will be emptied.

Now, the `discard` function of the relational model take into account
the x2many initial commands, therefore the x2many setting will stay
unchanged.

[1] : https://github.com/odoo/odoo/commit/9b81ddb993e4d56aba5aae637d160522d3af1d30

opw-4050990
opw-4092267
opw-4100926

Co-authored-by: Aaron Bohy <aab@odoo.com>

Forward-Port-Of: odoo/odoo#178039
Forward-Port-Of: odoo/odoo#177883

[IMP] project: {re,}schedule multi users tasks
Before this commit:
- {auto planning / moving forward and backward} tasks with multi
users is following the company calendar leading to create conflicts.
- a bug was found, the first possible date to plan is taking into
account the deadlines of the tasks that will be planned. for example
if task A is blocking task B and the deadline of A is 01/05/2023,
first planned date to plan for B will be 01/05/2023
then if A was planned with a new deadline before the old one 01/04/2023
so the old deadline should no more impact task B planned_date_begin.
- It's not possible to undo the scheduling if the user is not satisfied
with the result.

After this commit:
- tasks are planned in a time that would be suitable for all users.
- old deadlines of tasks to plan are no more taken into account.
- An 'undo' button in a notification toast after a smart
scheduling in the project task gantt view has been triggered. This
allows the user to rollback to the previous state.

Technically,
for move back/for{ward}, kahn algorithm with priority queue was changes
to a simple for loop.

why ? before this commit, an index is stored and keep incrementing for
each interval. There is no need to iterate intervals again as we're
pretty sure that previous intervals are used and the coming ones are
not used

but in this commit, a user availabilities can be in his intervals and
in another interval for his availabilities and another user, so there is
no way to be sure that coming intervals are not used as they can be used
in another context.

keep in mind, that in case of perf problems, it's possible to implement
again kahn approche and verifying if the coming interval is good or not
by comparing it with the used for planning, it's a bit complicated to
implement and maintain. but it's still a possible optimized solution if needed.

task-3853065