For instance, when a context was passed to a method, but no lang was defined in the context, it did not tried to fallback to other places where we could have find the user language.
Remove the intermediate rounding inside _compute_qty(), as it
is not necessary after rev. fa2f7b86 and has undesired side-effects.
An extra float_round() operation inside _compute_qty()
had been added at rev. 311c77bb to avoid a float representation
error in UoM factors that could bias the ceiling() operation
done as the last conversion step.
Example 1:
Dozen has a factor of 1/12, which was previously stored in the
database with a decimal accuracy of 12 significant decimal digits.
This meant the factor was exactly stored as 0.08333333333333.
When reading this back into a Python float, the precision was not
sufficient, and the UoM conversion of 1 Dozen to Units gave a
result of 12.00000000000047961...
After the final ceiling() operation to Unit's rounding, the
converted value ended up as 13.
This problem was initially solved using an extra rounding.
However at revision fa2f7b86 the decimal precision used to store
UoM factors was increased to preserve all significant digits.
This added the extra precision necessary to read the Dozen factor
back into an accurate float value of 1/12, and the conversion of
1 Dozen now gives 12.0 Units, even without the intermediate
rounding operation. (Works for other factor values too)
At the same time that extra rounding operation has undesired
side-effects, as it requires a fixed precision derived from
the rounding precisions of the UoMs. But there is no given precision
that would work in all cases for this intermediate value. It is
always possible to find a valid combination of UoM roundings
that breaks that intermediate step, e.g. by forcing integer
roundings.
Example 2:
Let Grams have a rounding precision set to 1 because no smaller
quantities are allowed, and Kilograms a rounding of 0.001 to allow
representing 1 Gram. (gram factor = 1000 and kilogram rounding = .001
by default)
If we try to convert 1234 Grams into Kilograms, the extra rounding
introduced in 311c77bb will cause a rounding of 1234.0/1000.0 at
the precision of Grams (1), which gives 1.0 as a result.
The net result of this conversion gives 1234.0 Gram = 1.0 Kilogram,
while the correct result (1.234 Kilogram) is perfectly compatible
with the UoM settings.
Similar errors could be triggered with various rounding settings, as
long as the intermediate rounding needs a finite precision.
Two extra tests have been added to cover Example 1 and Example 2.
--
Related to #2072, #1125, #1126, #2672Closes#2495, #2498
In graph views, fields from the pivot table were not translated in the user language
We pass the context, containing the user language, to fields_get in order to get the translation
This is also done by the search view, in search.js line 1978 at this rev.
opw-616713
In multi company environment, the company logo was not updated on company change in the user preferences
This disrupted the end user, as he might think the company change did not happen.
The name_get of res.partner.bank uses the format_layout to generate the name
of the bank. As every field is not required, we may get 'False' in the name.
Replace these missing values by an empty string.
Fixes#3590
prodlot_id field may be required due to constraint `_check_tracking`.
When a stock.production.lot is deleted, the constraint on linked stock.move is
not checked. To avoid inconsistency, restrict the suppression.
To allow the modification of existing stock.move, remove the states attribute on
the field definition.
As removal of serial may impact the traceability, it makes sense on buisness
point of view to force the modification of previous stock.move, even if the
constraint would not have been violated.
The list of linked stock.move is present on the serial form view making
the operation easier.
Fixes#3560, lp:1176912
Without this fix, if you have a new view in a module with active=False, the active tag will be ignore when upgrading the module because of 'update' mode, and the view will be activated by default !
Incorrect use of stock.move in product module + needs review.
This reverts commit 42f511405a4efe88e3903a4b4040ec9d83e462e2:
"[IMP] When no stock moves, change whatever you want, otherwise no change at all for UoM. #3440 Enhancement request richard-willowit"
The default UoM can only be changed when there are no stock moves (or only cancelled ones), but to any category.
The purchase UoM can be changed whenever you want, but has to be in the same category as the default UoM.
Closes#3440
[IMP] When no stock moves, change whatever you want, otherwise no change at all for UoM. #3440 Enhancement request richard-willowit
[FIX] Remove line
[FIX] Constraint should be applied when UoM or PO UoM is changed
Otherwise, in some cases, the categ_sequence can be set to null, which is not ordered the same way than 0, and you won't be able to sort lines with null and 0 as categ_sequence between each others
Fixes the issue #1216 (follow the link for more information). The issue
was caused by a hack in list view: the magical suffix __display is used
in render_cell to determine if a many2many field should be updated. This
commit simply makes sure that old many2many fields + __display keys are
cleared.
A better way would be to redesign/refactor the list view to avoid that
hack in the first place. But this would be a much more complex task.
When adding informational attribute, with only one possible value, it used to be skipped.
Instead keep it and add it on every variant.
To avoid dropping and recreating product (and lose eventual customisations), the attributes with only one possible value are set on every product.
This makes sure that in following test, these are not considered in variants_inactive variable.
Fixes#3204
if the bom is phantom and has no line, we attempt to find a new bom with the default product uom
This is possible that we find the same bom that the current one
In such a case, we must not explode, to avoid recursion.
Setting 0.0001 as precision used to be converted to 9.999999999999999e-05
precision_digits of 6 is the precision of the field 'rounding' on res.currency
Fixes#3875
This is safer to avoid inadvertently dropping customizations,
and does not impact the normal update/uninstall process, which
is based on the dependency order.
Xavier Morel
Arthur Maniet
Denis Ledoux
Christophe Simonis
Olivier Dony
Sandy Carter
Mohammad Alhashash
Will Stott
David Monjoie
Josse Colpaert
Jeremy Kersten
Maria G
Frédéric Van der Essen
Pierre Verkest
Mario Arias Badila
Edy Kendengis
Christophe Matthieu
Somesh Khare
Tymoteusz Motylewski
Martin Trigaux
happyraul
Danimar Ribeiro
Holger Brunn
Paul Chater
hiekmann
antonylesuisse