The browse_record prefetching algorithm attempts to
load data for all known records from the requested
model (i.e. all IDs present in the browse cache),
regardless of how indirectly/remotely they were
referenced. An indirect parent record may therefore
be prefetched along with its directly browsed children,
possibly crossing company boundaries involuntarily.
This patch implements a fallback mechanism when
the prefetching failed due to what looks like an
ACL restriction. This being a fuzzy concept at the
moment, it does its best to only catch a restricted
set of exceptions, and retry loading the data for
the directly requested ID only.
This may cause a small performance penalty in case
of real errors (with some spurious logging too),
but should only be triggered in very few cases.
The downside when this happens is that the prefetching for that
model gets effectively disabled, requiring multiple
SQL queries for further access to the data of
the other directly browsed records.
This EAFP approach seems safer and faster than
a LBYL technique where we would have to filter
all indirect m2o references according to ACLs
before allowing them to enter the cache.
lp bug: https://launchpad.net/bugs/1238042 fixed
lp bug: https://launchpad.net/bugs/1212429 fixed
bzr revid: odo@openerp.com-20131120100627-031fljyf4ckprc9b
Due to a framework limitation the virtual stock.picking.in
and stock.picking.out models need to duplicate the extra
columns added to the stock.picking master model.
This was only partially done, leading to errors in
some cases when stock.picking.{in,out} were directly
used by business methods.
bzr revid: odo@openerp.com-20131119181855-cciozs8fv3ll9bd8
- improved form: using acquirer.message to display custom message, like the account number
- added controllers; form will directly send to a controller that will validate the
sale order, then back to the payment checkout process.
bzr revid: tde@openerp.com-20131119180400-m6okb7empnpnre2p
- now going to shop/confirmation when coming back from the acquirer
- added poll on the confirmation page to wait for data from acquirer
- misc cleaning of checkout process, order and transaction management
- added cancel state on payment.transaction, when canceled by the
customer
bzr revid: tde@openerp.com-20131119160129-fkwkhjvk1bh0uarf
After discussion and addition of support for the methods parameter (on
@route), it's been determined that:
* POST endpoint must set up method correctly
* **kw on GET endpoints must be completely optional, mandatory query
arguments should be added as formal parameters without a default
values
* URLs can thus be generated for methods with **kw, simply by ignoring
it entirely
bzr revid: xmo@openerp.com-20131119154254-vp0zfnzjvi451vv0
This new code allows faster computation, because it avoids
- searching in a many2many relationship that is very costly in production
databases, because it is replaced by an 'id in [ids]' equivalent leaf
that can be huge.
- browsing in a create/write (should also lessen the number of issues
about read access rights in create)
A new optionnal parameter is given to the method, that are the
modified values. If this is not given (compatibility-mode) the
records are browsed to fetch the value.
bzr revid: dle@openerp.com-20131119135143-w4tcsnf8hdiyql0j
Gery Debongnie