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.
The old-api model._all_columns contains information about model._columns and
inherited columns. This dictionary is missing new-api computed non-stored
fields, and the new field objects provide a more readable api...
This commit contains the following changes:
- adapt several methods of BaseModel to use fields instead of columns and
_all_columns
- copy all semantic-free attributes of related fields from their source
- add attribute 'group_operator' on integer and float fields
- base, base_action_rule, crm, edi, hr, mail, mass_mailing, pad,
payment_acquirer, share, website, website_crm, website_mail: simply use
_fields instead of _all_columns
- base, decimal_precision, website: adapt qweb rendering methods to use fields
instead of columns
Rebranding has been done in:
- data/demo files
- html templates
- help notices
- comments
- logger messages
- and other various messages
(Commit taken from odoo-dev:8.0-improve-openerp-odoo-rlu at rev 7deaa08)
Closes#1260
A squashed merge is required as the conversion of the apiculture branch from
bzr to git was not correctly done. The git history contains irrelevant blobs
and commits. This branch brings a lot of changes and fixes, too many to list
exhaustively.
- New orm api, objects are now used instead of ids
- Environements to encapsulates cr uid context while maintaining backward compatibility
- Field compute attribute is a new object oriented way to define function fields
- Shared browse record cache
- New onchange protocol
- Optional copy flag on fields
- Documentation update
- Dead code cleanup
- Lots of fixes
- `delay` field on SO line moved to sale_stock, ignoring it for now
- avoid reusing the same bank account in 6.1 test, would cause a test
failure because the import would be skipped and the new partner
would have no bank account. Bank accounts should be unique in the
real world.
- log in DEBUG when a relationship record is skipped during EDI import
bzr revid: odo@openerp.com-20121019111100-dwf0crocqv43m3ij
As started in previous commits, in 7.0 there is no more
static storage of exported EDI documents, and they are
instead replaced by the improved portal - which will
provide the preview as well as export capabilities.
(The export might be added in a second phase)
bzr revid: odo@openerp.com-20121016122913-ndl0l36buhku3kxy
The EDI documents will now be generated on demand
and available from the Portal view of each document.
Instead of getting a link to a statically generated
EDI document, customers will receive a link to
the portal access to the document. They will be able
to signup on the portal the first time as well,
provided they are using the secure token that was
sent to them (i.e. the right link).
The link to pay online will be available in the
portal as well.
Still much to do, this is a small first step,
with edi.document renamed to edi.edi for
consistency, as it will not persist any
edi.document anymore.
bzr revid: odo@openerp.com-20121011152008-bht7ub6woaex0a7u
Now that res.partner does not allow name_create anymore
for usability reasons, we cannot depend on it, so we re-
implement it with create().
bzr revid: odo@openerp.com-20111220144131-1fbmx5vqckpofrkg
This is useful for transtyping documents, for example a sale.order
must be converted to a purchase.order when it is imported via EDI.
bzr revid: odo@openerp.com-20111006113319-ll5rfavzwzftkydb
Goffin Simon