Thanks for the patch, but it does not fix the problem. It's like putting a try/except when something crash instead of fixing the real issue. As an example, the problem reappear if you click "assign products" manually on a picking.
The real problem is why do we have several stock.move for the same product with non compatible UoM in the inventory ? What kind of manual operations allows this ?
This means we must add constraints. I propose this:
- You can never change the category of an existing UoM
- You can never change the UoM/Purchase UoM category of a product (you can change the UoM if it's in the same UoM than
before)
I am not sure, but these two constraints should be enough. I propose that the one who work on this bug tries a lot of scenario by changing/forcing the categories manually:
- change the UoM (another category) during inventory, pickings, stock.move, sale, purchase..
Hello,
Thanks for the patch, but it does not fix the problem. It's like putting a try/except when something crash instead of fixing the real issue. As an example, the problem reappear if you click "assign products" manually on a picking.
The real problem is why do we have several stock.move for the same product with non compatible UoM in the inventory ? What kind of manual operations allows this ?
This means we must add constraints. I propose this:
- You can never change the category of an existing UoM
- You can never change the UoM/Purchase UoM category of a product (you can change the UoM if it's in the same UoM than
before)
I am not sure, but these two constraints should be enough. I propose that the one who work on this bug tries a lot of scenario by changing/forcing the categories manually:
- change the UoM (another category) during inventory, pickings, stock.move, sale, purchase..
I reopen the bug and reject the merge proposal.