Commit Graph
8 Commits
Author SHA1 Message Date
Goffin Simon 0fd773a486 [IMP] Cleanup and refactoring of exception handling
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.
2015-01-16 17:15:18 +01:00
Denis Ledoux 11f52c9ee8 [FIX] payment_buckaroo: copy values dict to avoid altering original dict
_buckaroo_generate_digital_sign uses the values dict to generate the shasign
At some point, it alters the dict, it removes BRQ_SIGNATURE, but, as the values dict was not copied, it altered the original dict.
So, the key BRQ_SIGNATURE was not anymore present for methods called after _buckaroo_generate_digital_sign.
For instance, the overriden method form_feedback of website_sale payment
2014-12-19 17:51:19 +01:00
Denis Ledoux 2a10745d60 [FIX] payment_buckaroo: brq_test expects boolean 2014-12-19 11:57:03 +01:00
Denis Ledoux 7a75ab72f3 [FIX] payment_buckaroo: pudb introduced during dbe93ab022
Yes, shame on me. You can laugh.
2014-12-16 15:07:43 +01:00
Denis Ledoux dbe93ab022 [FIX] payment_buckaroo: partner lang can be set to False 2014-12-16 15:05:00 +01:00
Denis Ledoux e2ea82506e [FIX] payment_buckaroo: api expects iso culture as language param
IT looks like this is the code we use in partner lang, by replacing the '_' (underscore) by '-' (dash)
2014-12-16 12:14:16 +01:00
Denis Ledoux e6568e0d8c [FIX] payment_buckaroo: dynamic lang & test params
test flag is set according to acquirer environment
lang is set according to partner language
2014-12-16 12:06:59 +01:00
Thibault Delavallée d22e515d52 [MERGE] [ADD] module: payment_buckaroo acquirer: manage payments using Buckaroo. 2014-05-27 16:57:31 +02:00