Albert Cervera i Areny Dec 8, 2010
OpenERP offers a standard mechanism to add constraints on records. This is used, for example, in account.move.line to ensure no account of type view is used in an account move line. This functionality seems nice at first glance, but experience shows current constraints mechanism are really bad due to usability issues.
The reason is pretty simple. If we consider the example of account.move.line, it can happen that the user fills in a large bank statement and once it has finished tries to confirm it. That is the moment in which account moves are created and if only one of them is using an account of view type the user will always get the same message: "You can not create move line on view account.". Perfect. But which of the 100 lines the user has in the statement is the wrong one?
Something similar happens when developers don't think of this issue when raising exceptions. For example, if one of the 100 lines of the bank statement is already reconciled the user will get a very informative "Already Reconciled" message.
These are very important aspects in production environments and we've had to make several changes to improve exceptions, specially in accounting modules. A simple message such as "Account move line %s with debit %.2f and credit %.2f has already been reconciled." does the trick and can avoid lots of headaches to OpenERP users. Note that it's importat to take into account that if the record has just been created the user may not be able to find the offending record because the rollback of the transaction may remove it, so it's always good to give as much information as possible.
By the way, as you cannot give all the needed information in constraint messages by default, the best thing to do is to use the constraints mechanism but raise an informative exception from the constraint function instead of letting OpenERP return constraint's standard message to the user.