It happens that people modify the product on done stock.move.line
(it's not possible without customisation, at least allow to import or
to modify product and lot_id in the same view).

During the write on stock.move.line only the lot,locations,package and
owner are update on the quant. Not the product since it's not suppose to
be modify. It leads to a stock.move.line with a correct information but
a total mess on the quants with a lot updated and the previous product.
Since the product is not modified, the product on the quant and the
product on the lot linked to the same quant are different.

closes #43180

Task: 2119471
X-original-commit: f2a4f70
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

It happens that the `stock.quant.reserved_quantity` and `stock.move.line.product_qty`
for the same parameters are not equals (due to some bugs in the past)

It could implies that it doesn't exist enough reserved quantity on the
quant when a user try to unreserve a stock.move.line resulting in the
UserError 'It is not possible to unreserve more products of %s than you
have in stock'

However on current stable version (13.0 and 14.0) a lot of PR already
fixed a lot of issue as:
odoo#69377
odoo#66347
odoo#61758
odoo#54355
odoo#43180
odoo#70975
for example (there is more than that)

So the idea is to provide a way to unlock the database manually for
stable but not in the new version to be able to analyse them and find
possible bugs responssible for the desynchronization.

The server action check all the quants and their relative move line
to check if match correctly. If not it will remove the reservation
from both. It could remove the reservation from some `pickings` and
`stock.move`

related to odoo#62139

It happens that the `stock.quant.reserved_quantity` and `stock.move.line.product_qty`
for the same parameters are not equals (due to some bugs in the past)

It could implies that it doesn't exist enough reserved quantity on the
quant when a user try to unreserve a stock.move.line resulting in the
UserError 'It is not possible to unreserve more products of %s than you
have in stock'

However on current stable version (13.0 and 14.0) a lot of PR already
fixed a lot of issue as:
odoo#69377
odoo#66347
odoo#61758
odoo#54355
odoo#43180
odoo#70975
for example (there is more than that)

So the idea is to provide a way to unlock the database manually for
stable but not in the new version to be able to analyse them and find
possible bugs responssible for the desynchronization.

The server action check all the quants and their relative move line
to check if match correctly. If not it will remove the reservation
from both. It could remove the reservation from some `pickings` and
`stock.move`

related to odoo#62139

It happens that the `stock.quant.reserved_quantity` and `stock.move.line.product_qty`
for the same parameters are not equals (due to some bugs in the past)

It could implies that it doesn't exist enough reserved quantity on the
quant when a user try to unreserve a stock.move.line resulting in the
UserError 'It is not possible to unreserve more products of %s than you
have in stock'

However on current stable version (13.0 and 14.0) a lot of PR already
fixed a lot of issue as:
odoo#69377
odoo#66347
odoo#61758
odoo#54355
odoo#43180
odoo#70975
for example (there is more than that)

So the idea is to provide a way to unlock the database manually for
stable but not in the new version to be able to analyse them and find
possible bugs responssible for the desynchronization.

The server action check all the quants and their relative move line
to check if match correctly. If not it will remove the reservation
from both. It could remove the reservation from some `pickings` and
`stock.move`

related to odoo#62139

It happens that the `stock.quant.reserved_quantity` and `stock.move.line.product_qty`
for the same parameters are not equals (due to some bugs in the past)

It could implies that it doesn't exist enough reserved quantity on the
quant when a user try to unreserve a stock.move.line resulting in the
UserError 'It is not possible to unreserve more products of %s than you
have in stock'

However on current stable version (13.0 and 14.0) a lot of PR already
fixed a lot of issue as:
#69377
#66347
#61758
#54355
#43180
#70975
for example (there is more than that)

So the idea is to provide a way to unlock the database manually for
stable but not in the new version to be able to analyse them and find
possible bugs responssible for the desynchronization.

The server action check all the quants and their relative move line
to check if match correctly. If not it will remove the reservation
from both. It could remove the reservation from some `pickings` and
`stock.move`

related to #62139

closes #79180

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

It happens that the `stock.quant.reserved_quantity` and `stock.move.line.product_qty`
for the same parameters are not equals (due to some bugs in the past)

It could implies that it doesn't exist enough reserved quantity on the
quant when a user try to unreserve a stock.move.line resulting in the
UserError 'It is not possible to unreserve more products of %s than you
have in stock'

However on current stable version (13.0 and 14.0) a lot of PR already
fixed a lot of issue as:
odoo#69377
odoo#66347
odoo#61758
odoo#54355
odoo#43180
odoo#70975
for example (there is more than that)

So the idea is to provide a way to unlock the database manually for
stable but not in the new version to be able to analyse them and find
possible bugs responssible for the desynchronization.

The server action check all the quants and their relative move line
to check if match correctly. If not it will remove the reservation
from both. It could remove the reservation from some `pickings` and
`stock.move`

related to odoo#62139

X-original-commit: d99e173

It happens that the `stock.quant.reserved_quantity` and `stock.move.line.product_qty`
for the same parameters are not equals (due to some bugs in the past)

It could implies that it doesn't exist enough reserved quantity on the
quant when a user try to unreserve a stock.move.line resulting in the
UserError 'It is not possible to unreserve more products of %s than you
have in stock'

However on current stable version (13.0 and 14.0) a lot of PR already
fixed a lot of issue as:
#69377
#66347
#61758
#54355
#43180
#70975
for example (there is more than that)

So the idea is to provide a way to unlock the database manually for
stable but not in the new version to be able to analyse them and find
possible bugs responssible for the desynchronization.

The server action check all the quants and their relative move line
to check if match correctly. If not it will remove the reservation
from both. It could remove the reservation from some `pickings` and
`stock.move`

related to #62139

closes #81127

X-original-commit: d99e173
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Arnold Moyaux <arm@odoo.com>

It happens that the `stock.quant.reserved_quantity` and `stock.move.line.product_qty`
for the same parameters are not equals (due to some bugs in the past)

It could implies that it doesn't exist enough reserved quantity on the
quant when a user try to unreserve a stock.move.line resulting in the
UserError 'It is not possible to unreserve more products of %s than you
have in stock'

However on current stable version (13.0 and 14.0) a lot of PR already
fixed a lot of issue as:
odoo#69377
odoo#66347
odoo#61758
odoo#54355
odoo#43180
odoo#70975
for example (there is more than that)

So the idea is to provide a way to unlock the database manually for
stable but not in the new version to be able to analyse them and find
possible bugs responssible for the desynchronization.

The server action check all the quants and their relative move line
to check if match correctly. If not it will remove the reservation
from both. It could remove the reservation from some `pickings` and
`stock.move`

related to odoo#62139

closes odoo#81127

X-original-commit: d99e173
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Arnold Moyaux <arm@odoo.com>

It happens that the `stock.quant.reserved_quantity` and `stock.move.line.product_qty`
for the same parameters are not equals (due to some bugs in the past)

It could implies that it doesn't exist enough reserved quantity on the
quant when a user try to unreserve a stock.move.line resulting in the
UserError 'It is not possible to unreserve more products of %s than you
have in stock'

However on current stable version (13.0 and 14.0) a lot of PR already
fixed a lot of issue as:
odoo#69377
odoo#66347
odoo#61758
odoo#54355
odoo#43180
odoo#70975
for example (there is more than that)

So the idea is to provide a way to unlock the database manually for
stable but not in the new version to be able to analyse them and find
possible bugs responssible for the desynchronization.

The server action check all the quants and their relative move line
to check if match correctly. If not it will remove the reservation
from both. It could remove the reservation from some `pickings` and
`stock.move`

related to odoo#62139

closes odoo#79180

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

It happens that the `stock.quant.reserved_quantity` and `stock.move.line.product_qty`
for the same parameters are not equals (due to some bugs in the past)

It could implies that it doesn't exist enough reserved quantity on the
quant when a user try to unreserve a stock.move.line resulting in the
UserError 'It is not possible to unreserve more products of %s than you
have in stock'

However on current stable version (13.0 and 14.0) a lot of PR already
fixed a lot of issue as:
odoo#69377
odoo#66347
odoo#61758
odoo#54355
odoo#43180
odoo#70975
for example (there is more than that)

So the idea is to provide a way to unlock the database manually for
stable but not in the new version to be able to analyse them and find
possible bugs responssible for the desynchronization.

The server action check all the quants and their relative move line
to check if match correctly. If not it will remove the reservation
from both. It could remove the reservation from some `pickings` and
`stock.move`

related to odoo#62139

closes odoo#81127

X-original-commit: d99e173
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Arnold Moyaux <arm@odoo.com>

It happens that the `stock.quant.reserved_quantity` and `stock.move.line.product_qty`
for the same parameters are not equals (due to some bugs in the past)

It could implies that it doesn't exist enough reserved quantity on the
quant when a user try to unreserve a stock.move.line resulting in the
UserError 'It is not possible to unreserve more products of %s than you
have in stock'

However on current stable version (13.0 and 14.0) a lot of PR already
fixed a lot of issue as:
odoo/odoo#69377
odoo/odoo#66347
odoo/odoo#61758
odoo/odoo#54355
odoo/odoo#43180
odoo/odoo#70975
for example (there is more than that)

So the idea is to provide a way to unlock the database manually for
stable but not in the new version to be able to analyse them and find
possible bugs responssible for the desynchronization.

The server action check all the quants and their relative move line
to check if match correctly. If not it will remove the reservation
from both. It could remove the reservation from some `pickings` and
`stock.move`

related to odoo/odoo#62139

closes odoo/odoo#79180

Signed-off-by: William Henrotin (whe) <whe@odoo.com>