* 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
guessed_db is only computed by the /web controller, so even if the provided db
match the guessed_db we should save it in the http session. Because all rpc
call made before the authentication wont compute the guessed_db, so the
request.db will be wrong for those calls.
bzr revid: al@openerp.com-20131110010411-s7ermjwmfbile1ix
Depending on the way the search view is setup, a single item
(e.g. "Search foo for bar") can follow a list of a bunch of
completions. In that case, it is hard to notice that it's not just one
more item of said list.
Add a marker on the first of every completion list in order to catch
1-item lists (or lists without titles/categories) and prepend a small
border every time, so that single-element completions following
lists-with-titles can be noticed.
bzr revid: xmo@openerp.com-20131107112858-1xyvcesize0doblz
Similarly to the recent fixes in Purchase Analysis,
the Sales Analysis view must not group on the quantity
field. It is one of the columns that must be aggregated,
not used to fold PO lines into the same
result row.
The line count was also incorrect because of this, and
had to be corrected to actually count() the underlying
SO lines.
In addition, the JOINs were done in the wrong order,
which could cause problems (e.g. if an empty SO ever
landed in the database, all the SO line columns
would be empty in the JOIN, and cause errors)
bzr revid: odo@openerp.com-20131105103011-vkix07lsb6q3y9fd
The product quantity is one of the columns that must be
aggregated, not used to fold PO lines into the same
result row.
This, combined with missing aggregation operators
was causing multiple identical PO lines from the
same PO to be merged together and only counted once
in some aggregations.
bzr revid: odo@openerp.com-20131105101930-f2qbcp12luom08je