| Age | Commit message (Collapse) | Author |
|---|
|
Keeping the attachments widget on form views and document indexation (currently
limited to pdf/odt).
|
|
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.
|
|
rule prevent user from seeing duplicates
bzr revid: xal@openerp.com-20131216123954-px10qz9g3qxng6c6
|
|
bzr revid: al@openerp.com-20121217015651-qdw4iugzh9ghwv19
|
|
bzr revid: al@openerp.com-20121217014519-fwr5otel8qwlevaz
|
|
These commits were introduce mostly at revision
1849.1.1 revid:hmo@tinyerp.com-20081111052750-zqzvr6oaihvt103t
in an attempt to fix an issue with transactions
originating from FTP connections.
This was wrong: the virtual FTP filesystem should
perform its own transaction management for each
operation, just like the RPC layer does it for
each request. Forcing a commit in the business
code during the course of a normal transaction is
totally *forbidden*!
In addition, the FTP layer now properly manages
its transactions, so the commit calls were useless
anyway.
bzr revid: odo@openerp.com-20111130120239-5fcavvpd14w056zb
|
|
This will also enable the tests to run multiple times on the same db.
bzr revid: p_christ@hol.gr-20101012103936-d0e7o1b5ppu7kri5
|
|
yml is needed to be passed encoded, in order to display correctly
bzr revid: rpa@tinyerp.com-20100730091240-31ty2auvni191okv
|
|
This just suppresses a warning.
bzr revid: p_christ@hol.gr-20100713205421-th0c0vuohsum3vj8
|
|
bzr revid: p_christ@hol.gr-20100706121047-p2nex1m3g86nirt6
|
|
bzr revid: p_christ@hol.gr-20100701175132-ojsjqidcfegz9py8
|
|
There is commit commands inside document, to prevent from partially
writting data (eg. filestore and the db). Thus, the atomicity of the
transaction is broken.
bzr revid: p_christ@hol.gr-20100701175131-8v8xyosvz8nly0pi
|
|
bzr revid: p_christ@hol.gr-20100701175131-jltfosk4l5uvzo5l
|
|
bzr revid: p_christ@hol.gr-20100701175131-5acgsuetw1qx0juu
|
|
bzr revid: p_christ@hol.gr-20100701175130-bs2rx4w81ck6gh9l
|
|
bzr revid: p_christ@hol.gr-20100629140049-dowvybyjh6bncyrb
|
