The problem was that when the user manipulates the graph view (in pivot
table mode), the graph view resetted the group by facet in the search
view. It was not a problem unless a custom filter with a groupby was
already there, in which case, the group bys were duplicated.
The search view is now smarter, it only resets the additional groupbys
(and col_groupbys). Also, to prevent usability problems, the graph
view disable the '+/-' groupbys added by a custom filters.
Note that this fix is only temporary: a revamp of custom filters, facets,
search view is coming in the next months. (at least, that's the idea). Right
now, too much 'search logic' is in the graph view.
Another note: this fix is somewhat fragile: it makes some assumptions
about the search query (mainly that the custom filter is the first facet,
also, that no other filters add groupbys/col_groupbys)
[IMP] Add purchase order origin on picking
[WIP] Picking type on move for location on routing
[IMP] Provide extra function for custom buttons on picking
[IMP] Action assign optim
[IMP] Push apply should take invoice_state into account. Propagation of cancel of stock moves should depend on procurement rule
There's a little magic inside the website enabled route modifying the
context's lang, thus breaking the logic to print the report in the
current user's lang. The direct route to display the report should
stay in website_enabled mode, as it allows to switch lang, use the
website translator and so on.
When creating a new warehouse, the linked locations should have the same company as the warehouse.
The company_id field is required on warehouse (not necessary in vals as could be added by default values) while it is not for stock.location (meaning global location, also filled with default value).
When computing a field on a recordset, a subset of the records may be missing
or forbidden by access rules. In that case, evaluate the compute method record
by record, and mark failed records as such in cache.
Bootstrap's container class has a fixed width, using it in a modal
with the previous commit allowing an horizontal scrollbar makes the
layout goes crazy. Use container-fluid instead and cleaned some css.
The method onchange() executes onchange methods in cascade. Suppose onchange()
is called and a field F=1 in the form. If an onchange method set F=2, that
value is put in the result variable. If another onchange method set it back to
F=1, the binding F=2 must be removed from the result variable.
Fixes#2309
At 96f038a product-related fields were removed due
to an important product.template/product.product
refactoring. As the field values were simply
dropped, they may not be nullified when upgrading an
existing database. Forcing them to False will take
care of it.
Cascading onchanges can be caused by a related field computed in cache. This
causes a bug in sale order lines, were setting the uom field forces reading
product fields, which are inherited from product templates. The inherited
fields are computed as related fields, which marks the product record as dirty.
This subsequently triggers an onchange on the product field, which resets the
uom field!
Before this, the div wasn't in the right place in the form view
for instance, in the product form view, the third checkbox triggered this binary upload file
opw-613318
task-8982
Fabien Meghazi
Géry Debongnie
Daniel Reis
Jeremy Kersten
Josse Colpaert
Simon Lejeune
Denis Ledoux
Olivier Dony
Martin Trigaux
Christophe Simonis
Ronak Baxi
Raphael Collet
Pankaj Joshi
Frederic van der Essen
eneldoserrata
Christophe Matthieu