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