When the Bundle mechanism caches bundle files into the
ir.attachment table, it can sometimes cache an empty
resource file (For example, if a less/saas compiled file
results in an empty CSS file) for the bundle URL.
The appropriate behavior for _serve_attachment()
when the browser loads that bundle URL is to return
an empty file (which is the correct content), instead of
redirecting again to the same URL, triggering a loop.
In addition, this commit removes the special case for
returning 204 No Content. This HTTP status code is not
really meant for GET requests - returning an empty file
with a 304 or 200 code is more appropriate and allows
for normal browser caching.
Special case for binary attachments with an url, when there is no data
to serve. If the attachment name is an url, redirect to this url,
otherwise return a 204 HTTP error.
Commit 540b753bf8 introduced
support for resources stored as ir.attachment records in
asset bundles too.
This is specifically useful for customizations.
However the HTTP route for reaching those resources
when they are *not* in a bundle was originally created
in the `website` module (as a special handling for
404 requests)
This means that these dynamic resources would only
be partially supported when `website` is not installed,
causing various problems:
- missing resources in debug mode where bundles are skipped
- errors when trying to define new client-side Qweb templates
via XML resources - which are loaded with a direct request
- ...
This commit moves back the supporting code to the web module.
The `mimetype` column is not present in ir.attachment without
the `website` module, but sniffing it based on the attachment
name works fine at serving time too.
Closes#6002
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
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