| Age | Commit message (Collapse) | Author |
|---|
|
Reason: complete rewrite of the Sale module.
Responsible: fp, dbo, nim
|
|
|
|
- Preserved explicit 3rd-party copyright notices
- Explicit boilerplate should not be necessary - copyright law applies
automatically in all countries thanks to Berne Convention + WTO rules,
and a reference to the applicable license is clear enough.
|
|
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.
|
|
Let 2015 be a year without modelines!
cf #4174
|
|
bzr revid: vmt@openerp.com-20130415102349-vgcrfok2k5y10cwz
|
|
bzr revid: vmt@openerp.com-20121206145632-0h1coh5aaem65wsy
|
|
remove exclamation marks at the end of messages
remove first person usage ('I' and 'We')
remove unjustified capital letters
rephrase the clumsy form 'No <some attribute> is defined'
bzr revid: abo@openerp.com-20120806154410-kbf9aai2uzq2b0c4
|
|
bzr revid: pso@tinyerp.com-20120725113900-sx79bzkhh9812hib
|
|
bzr revid: pna@tinyerp.com-20120712070631-tat4ke05u0unftfw
|
|
instead of return {} in osv_memory/normal wizards.(lp:691544)
bzr revid: uco@tinyerp.com-20101228104445-h5q9jg8mq7dmdc51
|
|
checking for context from methods.
bzr revid: uco@tinyerp.com-20101213064309-vg36f1510xv2f8zb
|
|
account_analytic_plans: code cleaning
bzr revid: psi@tinyerp.co.in-20101011112550-ygkqmzmuhu1j7dm3
|
|
improvement.
bzr revid: vra@tinyerp.com-20100616115139-cql5oiqf622spa6p
|
|
bzr revid: mra@tinyerp.com-20100427050053-2e0xma7y41moxdnc
|
