Typically an exception during a JSON-RPC request must be
handled specifically and return a JSON-RPC error in all
cases. Previously the _authenticate() step could fail
during ir_http.dispatch() and bubble up to werkzeug,
yielding a dumb "Internal Server Error 500" even for
a JSON-RPC request.
bzr revid: odo@openerp.com-20140328142748-00haplmkc3fv6f9y
In some cases the authentication check can fail
for an unknown reason (e.g. connection pool is
temporarily full). This should not be treated
as an authentication failure, as the status is
really unknown. Let those exceptions bubble up
instead.
bzr revid: odo@openerp.com-20140228170712-l8smq6u3cmvjtd5e
[MOV] ensure_db() helper from http module to web module
Since we removed auth="admin" in favor of auth="none" with explicit superuser id usage,
the disable_db clause in auth_none() has only sense for the /web and /web/login routes.
The web module is an exception because it's routes are registered for the nodb dispatching.
This is why the ensure_db() helper is moved to web client and will take care of the
web's auth="none" routes that needs a db to work with
bzr revid: fme@openerp.com-20140130092152-h6elwf2yerhd9xey
[REF]Add _auth_method_public into server/addons/base/ir/ir_http (removed from website/ir_http)
Related commit for Addons : Committed revision 10689.
bzr revid: jke@openerp.com-20140128145510-3byhdmwftloeod6s
main problem, view inheritance model field would use model from the
root view (after following inherit_id links) rather than the base view
(the requested one) -> with divergent models, it was possible for the
requested view itself to never be returned.
bzr revid: xmo@openerp.com-20131212134422-uxg6h21w1jhth9ow
* make ModelConverter use its regex for data extraction so
replacements can just fixup the request and don't have to mess with
_uid
* replace routing_map property by method, for unknown reasons the
property does not work at least overridden (it's not found) and I
don't care enough to wonder why
* arguments result from MapAdapter.match() is a mapping, not a
sequence. Iterate through values()/itervalues() otherwise we'll
never get a browse_record to do the uid substitution on, only
strings (params names)
* inject arguments from URL map/match into the function before
executing it, this was apparently lost during the transition
* reintroduce get_db_router for third-party code needing to generate
URLs
bzr revid: xmo@openerp.com-20131115124819-bp4gjpfdlda2qyf5
* fix nameerror on SessionExpired exception not being imported
* remove pointless RequestUID instantiation by single placeholder object
- may be replaceable with a LocalProxy or something along those lines?
* rename default/nodb routing map
* make better use of werkzeug API
* move lazy routing_map instantiation to property in ir_http.find_handler
- do we have some sort of lazy_property?
bzr revid: xmo@openerp.com-20131115100901-s3skmwv9d1jgk9y0
Allow module to override the http dispatching process:
- The default implementation uses werkzeug.routing but any other method could
be used, it'a also possible to pre/postprocess (i.e. url aliases)
- Authentication (auth param on route) is plugggable by defining now
_auth_method_<methodname>
- Error handler are overridable, any module can define a new exception and
handle it by orverriding the _handle_<error_code> method.
- Add model converters for routes, to directly get the browse record example
@route(['/job/detail/<model("hr.job"):job>'], type='http', auth="user")
This is done by splitting dispatching, when the db is unknown low level http.py
dispatching is used, it's only used by a few controller in base and web. When
the db is known, ir_http is used because it's a regular Model it is fully
overridable by openerp modules.
bzr revid: al@openerp.com-20131110142731-qi9910fkty25cdtd
Split low level dispatching and high level dispatching.
Low level dispatching is used when the db is unknown it's only used by a few
controller in base and web.
High level dispatching is used when the db is known, it is used by most
controllers and it handles authentication and errors. Because it's a regular
osv object all it is fully overridable by openerp modules.
bzr revid: al@openerp.com-20131110014609-io03vspj2q1wtqa0
Christophe Simonis
Olivier Dony
Fabien Meghazi
Antony Lesuisse
jke-openerp
Xavier Morel