Unify and refactor exception handling in framework and addons.
The generic `except_osv` is now deprecated, and replaced by more specialized exception subtypes:
- `UserError` (renamed from Warning, as it conflicts with the built-in `Warning`) raised when a non-technical error occurs during a business operation. It could be a missing information in the data provided by the user, or a misconfiguration.
- `AccessError`: raised when any operation is denied because the user conducting it does not have the required access rights.
- `AccessDenied`: raised when an operation that requires authenticated access is attempted via an unauthenticated request.
- `MissingError`: raised when an operation is attempted on a record that does not exist.
- `ValidationError`: raised when an operation violates a SQL or Python constraint.
- All other exceptions are internal errors due to a system problem or bug, and raised untouched to the client-side, which should display a traceback.
All exceptions take a single message argument.
The `test_exceptions` module has been updated to showcase both new and old (deprecated) exceptions.
A great many old `except_osv` had a useless title with "Error!" or "Warning", those have been removed, as this is handled by the client-side widget that displays the messages.
This commit introduces a more consistent policy for logging errors and warnings:
- All messages that do not require administrator attention should be logged at INFO level or lower. This includes all errors that are notified to the user in a friendly manner, even for access right problems or validation errors during business operations.
- All messages that indicate a likely misconfiguration or malicious use by the users should be logged at WARNING level, as they typically require administrator attention.
- All other unhandled internal errors cannot typically be handled by the user and should be logged at ERROR or higher level, as they require immediate administrator attention.
If a wizard is launched from an embedded view list, only the record of the line from which the wizard was launched is reloaded after closing the wizard.
In this specific case, as new lines are added to the picking, we need to fully reload the stock picking
[IMP] Provide better purchase order picking type
[IMP] Possibly a better product uos handling in the sale order line
[FIX] Recreate of delivery order when sales order in shipping exception
[FIX] Delivery method should be passed to delivery order
Don't override the location_id if the super get_default don't retrun a value.
Else it is impossible to set a default value, because the ir_values is always overrided with stock_location_stock as location_id
bzr revid: jke@openerp.com-20140320180240-un42lptu3pjnsmxq
bugs fixed:
1) do_unreserve() on stock.move was setting back to 'confirmed' state also moves in 'done' or 'cancel' state
2) in return picking wizard, unreservation of quants was made only on the chained operation regardless if it had been split before or not
3) lot management in return picking wizard
4) new implementation or return picking wizard in order to only allow a manual fixing
5) uom support in return picking wizard
bzr revid: qdp-launchpad@openerp.com-20140206123852-g22nkgcxud0c9tzr
Goffin Simon