One of the most annoying things (if not the most) in our experience with user support is when the application does not provide enough information when there's something wrong with user input.
Our OpenERP branches are full of patches that introduce more information to those exceptions and I think we should try to do better in Tryton. Let me put just a couple of examples, but there are tens like this: In 'stock.move' there's the product_type constraint (doesn't accept services) but when it happens it won't tell you which is the offending product and move. In 'account.move' you cannot post an unbalanced move, but you don't know which one it is. On the other hand, if you try to modify a posted one, you *do* get the appropriate message telling you which is the offending move you're trying to modify. Those things are not very important when you're operating on a single stock move or a single account move, of course, but it is when other processes operate on them (such as a shippment) or there's an action to apply to a set of them (such as posting a set of account moves). Fixing the cases when one uses 'raise_user_exception' is quite simple because you simply have to improve the message and that's it. When it comes to simple (python) _constraints, what we do is raise a user exception instead of returning False because it's the only way showing enough information. I comment in one of my latest patches tells me to return False, but I think we should find a solution for this if we do not want to raise exceptions. I must say, I think it is a valid solution to raise an exception and we could even change the _constraints behaviour to simply expect the programmer to raise the exception instead of acting on the result of the function. The main issue is for _sql_constraints. We currently do not have a solution for that, even if it would be nice to know which is the record that raises the exception. So the idea with this e-mail is to try to make everyone aware of the problem and propose to change the behaviour in _constraints mechanism to force the programmer to always raise an exception. -- Albert Cervera i Areny http://www.NaN-tic.com Tel: +34 93 553 18 03 http://twitter.com/albertnan http://www.nan-tic.com/blog -- [email protected] mailing list
