The stdlib version of the json library is more recent than the 3.5.3
version we are pinning in `requirements.txt`
There is no reason to use it.
Closes#6940
QWeb's LazyResponse mechanism allows controllers to be inherited
and to alter the rendering context (qwebcontext) *after* calling
super().
However it caused the final rendering to occur outside the protection
of the @service.model.check decorator that handles concurrent access
errors. In rare cases the lazy rendering can be interrupted by
a concurrent access error, for example when bootstrapping the
the cache of asset bundles (as it INSERTs a bunch of attachments).
By forcing the flatten()ing of the lazy response earlier, right
after calling the route's endpoint(), it occurs within the
protection of the @service.model.check, and benefits from the
automatic retry.
flatten() was modified to avoid rendering twice the template
The flatten() in get_response() is still necessary for addons
code that directly calls get_response().
Moved QWebException into openerp.exceptions next to the other
exceptions classes - since it now has more global semantics.
~
The whole request dispatching code could really do with a
complete redesign/simplification.
Request arguments were being stored on the routing
endpoint during the dispatching.
This could cause request0 to use parameters from request1
if request1.set_handler() is called before request0's
dispatching is over. No reason to store request arguments
on routing endpoints anyway.
In method `user_has_groups`, make "Technical Features" effective in debug mode.
Make the group "Employees" inherit "Technical Features".
Make the group "Technical Features" invisible in the user form view.
Remove useless `ir.rule` attached on group "Technical Features".
Fix `test_acl` by avoiding the tricks around the group "Technical Features".
When storing files send in POST in session_store, store them with a
name based on the name of the session file itself (ease matching sessions
and files for debugging purpose)
POST requests on routes with auth="user" are now correctly handled when
the user is not connected. Request data (form and files) are stored in
the session. Once the user is logged, redirect her to a specific route
that will reprocess the original POST request.
Since 31d817e, we rotate then session at login/logout.
Unfortunatly, `openerpframework.js` does not support session id change
at authentication and keep old one.
In order to keep compatibility with existing js clients (including 7.0
ones), we do not rotate the session at authentication.
Fixes#6948Closes#6949
return request.not_found crash with a internal error, because get_response
takes a environment as param.
Werkzeug Documentation:
Keep in mind that you have to pass an environment to get_response() because
some errors fetch additional information from the WSGI environment.
The `rotate` flag introduced by 31d817e849
was initialized at the very end of the session init, after
the reset of the `modified` flag.
This had the side-effect of marking the session as modified
for every request, saving the session to disk every time
even without any change.
Closes#6795
- remove useless cache clear_prefix
- add a route cache attribute when used it will save the rendered page into the
ormcache for the specified time, this is only enabled if the user is public
and reponse code is 200
- enable it on /page controller for 5min
This fixes an issue in property `field.digits` that cannot find a valid cursor
to the database. Forcing the instantiation of an environment makes the cursor
retrievable.
When returning an HTTPException e.g. by calling ``request.not_found()``
which returns a ``werkzeug.exceptions.NotFound()``, the http system
would log a warning as HTTPException is neither a subclass of Odoo's
Response nor a subclass of werkzeug's BaseResponse.
Move the string response case about (for flow clarity), and convert
HTTPException instances to Werkzeug responses then fall into the normal
BaseResponse -> Response case to ultimately get an Odoo response object
out of the HTTPException instance.
Completes/improves fd6dde7ca
Because Werkzeug uses/provides flow-control exceptions via
HTTPException (which can be used as straight responses) they are used in
a few places of the web client, when triggering some redirections for
instance.
Breaking into the debugger for such mundane situations is surprising and
inconvenient for developers trying to debug actual issues in the system,
even though HTTPExceptions are by and large not error per-se, and
shouldn't warrant triggering post-mortem debugging.
So in the non-RPC dispatcher, don't post-mortem on HTTPException either.
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 log level rec.request and rpc.response where no longer logged as
the webclient no longer uses XMLRPC but JSONRPC instead.
Duplicate the logging part from dispatch_rpc to dispatch method of JsonRequest
to add rpc logs when using JSON requests.
opw 617490
Leonardo Rochael Almeida