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.
purchase_requisition/wizard/purchase_requisition_partner.py
* [REF] In create_order() method, move stuff of creating purchase order into 'purchase.requisition' object.
purchase_requisition/purchase_requisition.py
* [ADD] introduce new method: make_purchase_order()
- to create new RFQ of specified supplier with plannned date, price
bzr revid: hmo@tinyerp.com-20111202072755-e3ura2cmnh78utet
purchase_requisition/purchase_requisition.py
* [IMP] call tender_done() method instead of set state manually.
purchase_requisition/purchase_requisition_demo.xml
* [IMP] added demo data of requisition with RFQs
purchase_requisition/wizard/purchase_requisition_partner.py
* [IMP] address_id is not mandatory. so remove required tag
[IMP] Test cases of requisition process
* purchase_requisition.yml
* purchase_requisition_demo.yml
[REM]
* purchase_requisition_exclusive.yml [move into requisition.yml]
* purchase_requisition_report.yml [move into requisition.yml]
bzr revid: hmo@tinyerp.com-20111202051506-kmlsfqnoqcafkic5
Goffin Simon