Currently, when using a cash rounding method with the strategy `Modify tax
amount` on a Pos config, an error message appears upon trying to close the
session.

Steps to reproduce:
-------------------
* Create a cash rounding method with strategy `Modify tax amount`
* Open pos setting and apply the cash rounding method
* Open pos session
* Make an order that will trigger the cash rounding
* Validate the order
* Try closing the session
> Observation: The operation cannot be completed: Missing required account
on accountable line

Why the fix:
------------
Prior to 18.0, the point of sale would only allow rounding methods using
the strategy `add_invoice_line`.
https://github.com/odoo/odoo/blob/786abeb0783461d555c4077b8258490a7aed8c21/addons/point_of_sale/models/pos_config.py#L302-L314

This constraint was removed in this commit to also allow using `biggest_tax`
strategy:
[8fb7e5f#diff-4c6e412c7d8f4df2a05831547e7df93d0b91f510d03b7b3ed0d689a18f5dae44](https://github.com/odoo/odoo/commit/8fb7e5fd304697aebcce085602a5f3a1ecaf757a#diff-4c6e412c7d8f4df2a05831547e7df93d0b91f510d03b7b3ed0d689a18f5dae44)

This is a temporary fix bringing back the constraint has the pos wasns't
fully ready to use it. It will be remove later when the integration is
complete.

opw-[4673618]

Forward-Port-Of: odoo/odoo#204943

Before this commit, when the user enables the task dependencies feature globally, all basic projects (that is, non fsm ones) will get the feature. By doing that, the open tasks state will be recomputed to set `Waiting` state on tasks with blocking tasks linked to them. The problem is the compute method of the task state will also reset the state instead of keeping the one set on those open tasks when there is no blocking task linked.

This commit makes sure the compute method of task state field is no longer called when the task dependencies feature changes. Instead, a inverse method is added on allow_task_dependencies field on `project.project` model to correctly update the state of the tasks linked to the project in which the task dependencies feature changed.

Steps to reproduce the issue:
----------------------------

0. install project
1. Create a project
2. Create some tasks inside that project and changes the state to some tasks
3. Enable the task dependencies feature in `Project > Configuration > Settings` menu.
4. Go back to the tasks kanban view of that project.

Current Behavior:
----------------

The state of those tasks is reset to `In progress` (if those tasks did not have a state equals to `Done` or `Canceled`).

Expected Behavior:
-----------------

The state of those tasks should not be altered since no dependencies are added in those tasks yet.

task-4487922

Forward-Port-Of: odoo/odoo#206371
Forward-Port-Of: odoo/odoo#198952

Steps to reproduce the issue:

- Add a popup with a 0.0001 days config.
- Visit the page as a non-connected user.
- The popup opens at some point.
- Close the popup.
- Wait 10 seconds.
- Refresh the page ---> The popup never reappears.

This issue comes from the fact that we were setting a non-integer value for the cookie expiration. The "max-age" attribute does not accept float values, so the cookie is treated as a "session" cookie. It only expires when the session ends, which can be effectively "never" on some browsers that keep sessions open indefinitely.

This used to work before commit [1] because we were also setting an "expires" attribute. When the "max-age" attribute was invalid, the browser would fallback to the "expires" attribute. Since that commit removed the "expires" attribute, the only remaining value (max-age) is invalid, and the popup never reappears as expected.

This fix ensures the value used in "max-age" is always an integer, avoiding any invalid cookie behavior.

[1]: https://github.com/odoo/odoo/commit/006ee1fc470eabdcbde68077259cf543633d6490

task-4690318

Forward-Port-Of: odoo/odoo#206429

### Steps to reproduce:
- Create a storable product tracked by lot and avco valuated.
- Put 10 units of that product in stock withtout set lot.
- On the stock quant, click on history
- Modify the inventory adjustment move to set a quantity of 3 and a lot.
- Inventory > Reporting > Valuation
#### > Stock valuation layer inconsistency: +10, -10, -7, +3 > the -7 should not be there

### Cause of the issue:

If you change the quantity of a move line you will automatically reconcile the quantity difference because of these lines: https://github.com/odoo/odoo/blob/6f3f89f55ab67d39b2487fdf8220747f568b7eb0/addons/stock_account/models/stock_move_line.py#L34-L36 However, if you change the lot of your move line you already plan to conter balance the entire quantity of the previous lot because of these lines:
https://github.com/odoo/odoo/blob/6f3f89f55ab67d39b2487fdf8220747f568b7eb0/addons/stock_account/models/stock_move_line.py#L37-L46 In partciular, the first reconciliation should not be performed in case we change both the quantity and the lot of the move line.

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

Forward-Port-Of: odoo/odoo#204960

The issue was introduced by:
https://github.com/odoo/odoo/commit/90158f647ba610b31499555641c9db8450b49c4c

The issue has been fixed by:
https://github.com/odoo/odoo/commit/b1666c61bbc9d7e7b920483e168c6048ecde011c

This commit is adding a test for it.

**Steps to reproduce:**
- Install Accounting and purchase_stock
- Activate a foreign currency (e.g. Euro)
- Create a PO:
  * Vendor: [any]
  * Currency: EUR
  * Product: [any with a Unit Price and a tax]
  * Payment Terms: [any] (e.g. 15 Days)
- Confirm the PO
- Validate the receipt order
- Go to "Accounting / Vendors / Bills"
- Create a new bill
- In "Auto-Complete" field, select the created PO

**Issue:**
A traceback is raised due to a division by zero.

**Cause:**
The bill and its lines are created from some information coming
from the PO.
In the computation of the needed terms of the bill, a computation
of the taxes is called on the lines (i.e. _compute_all_tax).
During that computation, the rate is computed as followed:

(*) rate = line.amount_currency / line.balance if line.balance else line.currency_rate

and later, rate is used as followed:

'balance': tax['amount'] / rate

When "purchase_stock" module is not installed, there is no issue
because "_prepare_account_move_line" method from "purchase.order.
line" model doesn't initialized "amount_currency" nor "balance".
Therefore, the result of (*) falls back on "line.currency_rate"
which is not zero.

However, when "purchase_stock" module is installed, "balance" is
initialized in "_prepare_account_move_line" but not "amount_currency",
leading a result of 0 for (*).

opw-4681735

Forward-Port-Of: odoo/odoo#205233

### Steps to reproduce:

- In the settings enable "Rental transfers"
- Create a storable product that can be rented put 100 units in stock.
- Create a rental order for 10 units of that product planed for the period : [today + 2 days, today + 3 days] and confirm it.
- Create a rental order for 10 units of that product planed for the period : [today + 1 days, today + 2 days] and confirm it.
- Look at the forecast rentable quantity.
#### > It should be 90 but it is 100.

### Cause of the issue:

Since c18a7d2dc36d33134c5bdb1569865bd554e04130, the rentable forecast for future dates ignores the `rented_qty_during_period` if the setting "Rental transfers" is enabled. This happens because that rented quantity during period is supposed to be absorbed by the stock forecast: https://github.com/odoo/enterprise/blob/8ea5f4f9a0a907c57844c6274688171193f6a904/sale_stock_renting/models/sale_order_line.py#L132-L134 
However, the stock forecast of the 'virtual_available' relies solely on deliveries and receipt happening prior to the start of the renting period. Therefore the rental orders that are planned to start during the renting period should still contribute to the
`rented_qty_during_period` in that use case.

opw-4552760

Forward-Port-Of: odoo/enterprise#83262
Forward-Port-Of: odoo/enterprise#82172