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
This assumption is incorrect in OpenERP v7. The WMS
design in OpenERP 7 and previous versions only permits
tracking production lots (aka serial numbers) on
incoming moves, outgoing moves and production moves.
You can specify production lots on internal moves too,
but the system will also generate internal moves for
many reasons, and nothing guarantees that they will
have the right lots assigned.
This is a design decision, and this means that we
must never enforce the availability of specific
production lots.
This features will be available in OpenERP 8 through
the use of an extra concept called "Quants", that
will make this kind of tracking possible.
bzr revid: odo@openerp.com-20131112153925-1s2b8f2eo568wpxh
The procurement workflow has a magic `bypass` transition
that acts as a fallback for MTO procurements in case the
necessary modules are not (yet) installed. For example
it will consider a MTO+Buy procurement directly satisfied
if the Purchase module is not yet installed.
However this bypass transition did not properly take
"internal pulled flows" into account, which are added
by the `stock_location` module as a third kind of procurement
type. In this case the bypass would match and never
give stock_location the chance to run.
In order to be consistent with the other procurement
methods, the bypass transition needs to be adapted.
Also updated the check_move() method to make it more
explicit rather than a side-effect.
bzr revid: odo@openerp.com-20131112151747-da67h4yavhz3k29c
This dummy button is only meant to save the
order and refresh the view, which is easily
accomplished by sending an non-existing
workflow signal. Setting the button type
to the default `workflow` type (or simply
removing the wrong type) fixes the problem.
bzr revid: odo@openerp.com-20131107110256-zfok0mwkbesrkf81
This can create inconsistencies in the warehouse inventory
in case delivery orders are not customer-specific, e.g.
when using the POS.
When there is no destination customer we can still use
the default Customers locations.
bzr revid: odo@openerp.com-20131107105302-hf8lublc1x3qc87h
The access right test expect an exception
to be raised when accessing any of the
followers, but this is not 100% correct,
as the test user (Chell) should be able to
read her own record.
This worked by chance because the ORM
prefetching was triggering an access error
whenever any follower was accessed, but
this was a bug, now fixed in server at
rev-id odo@openerp.com-20131119153700-5sbo2cl13vvqsgz5
revno 5136
bzr revid: odo@openerp.com-20131119175658-1nv5c9iwfizkrasc
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
Country data is incorrect for Venezuela, the country currency is VEF not VUB (the old ones) wich technically is incorrect too because it was VEB.
bzr revid: odo@openerp.com-20131114230223-6cvybpthj70hr81m
When no other module is installed, no change of behaviour (check_move returns None, always True)
When stock_location is installed, depending of the order of evaluation of the conditions, could go to ready without passing by move activity, avoid this
Courtesy of Mohammad Alhashash
lp bug: https://launchpad.net/bugs/1193779 fixed
bzr revid: mat@openerp.com-20131114162553-5yzgp4hy9dqdan5t
if no registry exists and several calls to RegistryManager.get() are called at the same time
by several threads, several registries will be created one after the other and only the last
one will be kept in cls.registries (courtesy of Guewen Baconnier (Camptocamp)
Invert behaviour of commit 3685 because, at that time, the new trigger the schedule_cron_jobs method which ran another lock and called get on the registry. We had a deadlock with the cron. This is no longer the case as we don't call the same method at the end of the creation of the registry and it does not trigger a lock
bzr revid: mat@openerp.com-20131114144401-k00podawlem7cjd1
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: tde@openerp.com-20131114113231-oyk16t9i3m3wul6k
Martin Trigaux