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
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
It is a common need to set a higher decimal precision
for `Product Price` (i.e. the product cost field) for
high volume / low value items. This may typically
require up to 4-6 decimals for e.g. EUR/USD-based
companies where the currency has 2 decimals.
In that case the product cost should be stored with
full precision without applying the currency rounding.
The appropriate currency rounding will be applied
anyway as soon as a transaction actually uses that
product cost (typically in a SO/PO)
bzr revid: odo@openerp.com-20131104173232-84g115x6ykxoc1rh
While processing a picking we must keep track of
previously processed lines as they modify the
stock on hand but are not yet included in the
`qty_available` function.
Negative stock on hand is handled as if
the stock was zero as far as the average
price computation is concerned.
bzr revid: odo@openerp.com-20131104171245-z1lgsplyu4cdz9gc
Without the right precision the default rounding is
applied and causes a possible loss of precision when
the `Product Price` precision is increased.
This can in turn lead to incorrect average price
computations.
bzr revid: odo@openerp.com-20131104170118-ls5q0yridevw0jgt
The starting table for Purchase Analysis is purchase_order_line
not purchase_order. The previous code was using a wrong JOIN
combination starting from purchase_order, which resulted in
a crash if an empty PO was created.
In order to prevent this an extra WHERE clause on product_id
being NOT NULL was added, but this was incorrect too as it
prevented PO lines with no product_id value from appearing
in the Purchase Analysis results, while being perfectly valid.
bzr revid: odo@openerp.com-20131104165826-kltuzlh4i8q89sk0
When processing a translation, the module used to replace the original term by the translated value for accounts (only object with force_write=True). Now getting real multilang feature.
Generates the accounts with no language to get the untranslated value
bzr revid: mat@openerp.com-20131104095729-hwh2cocudxnhunyz
message_update. This behavior makes sens only in message_new when
setting initial parameter of the applicant, not when somebody sends
an email on the record.
Removed priority change when there is a 'priority' key in msg; but
this key is not likely to be present in a parsed email.
Removed updated values change due to a mapping of values present in
the email. This code was a copy-and-paste from crm and did not have
any meaning in hr_recruitment.
Also removed unnecessary code in project, project_issue, crm_helpdesk
and crm_claim for the same reasons as for hr_recruitment.
bzr revid: tde@openerp.com-20131104092731-ixasweoy1dbllbb3
When creating a new Date object at a specific date, this date is treated as a UTC datetime
then normalized to the browser timezone. This can lead to a change of Year/Month/Day depending
of the chosen date. Using a date of a leap year date for date parsing and forcing UTC date for
datetime parsing correct the month-switch errors in all timezones
bzr revid: chs@openerp.com-20131031133920-yl5z4oz939smwvz8
Denis Ledoux
Martin Trigaux
Thibault Delavallée
niv-openerp
Christophe Simonis
Olivier Dony
Launchpad Translations on behalf of openerp