In manufacturing bom lines, digits_compute is set
to the precision 'Product Unit of Measure'.
It should be the case as well in the produce wizard,
otherwise you won't be able to change the quantity
within this wizard to the according product quantity precision
opw-629657
BOM Lines are ordered by a sequence field,
the "handle" widget makes even possible the lines reordering.
The order was respected within the mrp.production
(in o2m products to consume and consumed products)
but not within the mrp.product.produce wizard
opw-629629
When comparing a float value to 0.0,
it can happen the float value is very near to 0.0,
but not exactly 0. This is the point to use float_compare,
```float_compare(qty, 0, self.pool['decimal.precision'].precision_get(cr, uid, 'Product Unit of Measure'))´´´
will compare qty to 0, with the product unit of measure precision (0.01 by default).
So, if qty is equal to 0.00001, this means the qty is regarded as equal to 0.0.
(float_compare will return 1).
During the delivery of a picking the procurents in exception or canceled are
reset to confirm state.
As the list of picking was a list shared in the loop, other procurements may be
reset to confirm as well.
This search view option was properly set but not
observed by the search view itself.
This caused all related links and smart buttons
to open a list of records that was wrongly filtered,
as soon as a default filter was applicable to the
target action (e.g. with default filters gloablly
set per model, not per action).
This regression was introduced at refactoring
commit d8d6311b50
Allows exporting fields whose string is a non-ascii *byte*string (rather than unicode).
backport of 7286f4e424 fixing #773 to branch 7.0 by request of @flotho
When changing e.g. from 3-step to 2-step, we would like to deactivate a location,
but maybe the user still wants to use that location e.g. in a rule on the product, so do a check
if it is not used in some route not related to the warehouse.
This issue is related to
http://bugs.jqueryui.com/ticket/8656http://bugs.jqueryui.com/ticket/8749https://github.com/jquery/jquery-ui/commit/d693ce5324f6f3be8479ef083e4eaf3c705ef043
When opening a form view, scrolling down,
and opening a many2one dropdown menu,
the dropdown menu wasn't directly under its input.
It could be really problematic when the menu was not even
visible on the current browser page (when you had to scroll down
a lot to access the many2one input).
The issue was resolved as soon as you opened the dropdown
menu a second time, and did not happen if you didn't scrolldown.
But, on initialization, the dropdown menu wasn't at the right position.
Fixes#5603
opw-629601
Amount in payment order is not correct if the account move
line has already been paid by another way. The right amount is
in the residual field related with move_id to the account invoice.
opw:628903, 628428
Text fields, or char fields having widget="text",
were not sized correctly when the field was not
visible by default, ans was set visible thanks
to attrs and other fields values.
opw-629394
Before this revision, the overdue payments report contained all payments due,
including the ones in the future, that are not actually due yet.
opw-628874
Christophe Simonis