Conversation
This recently added feature is counter intuitive, error prone and is already causing bugs in sale_workflow.
There was a problem hiding this comment.
I agree you want to check the exception on a selected set of object. When you start to have thousands of objects this feature is meaningless and resource greedy.
Just got some MemoryError due to this lastly being run while preparing data with onchanges with addition of a api.constraints which was making the check on all the 3.1 M sale order lines in the system. That was not easy to spot. Thanks for the fix!
|
/ocabot merge major |
|
Hey, thanks for contributing! Proceeding to merge this for you. |
|
Congratulations, your PR was merged at 02d1a55. Thanks a lot for contributing to OCA. ❤️ PS: Don't worry if GitHub says there are unmerged commits: it is due to a rebase before merge. All commits of this PR have been merged into |
Syncing from upstream OCA/server-tools (16.0)
This recently added feature is counter intuitive, error prone and is
already causing bugs in sale_workflow.
Like this:
https://github.com/OCA/sale-workflow/blob/10.0/sale_exception/models/sale_order_line.py#L28
I think it's the correct and obvious way to write this code. But the actual implementation, will fail if the sale order has no lines. It will test exceptions on all the sale order line (empty self = search([])) and return exceptions tied to other sale orders.
Please merge it with a major version number bump.