For report with duplicated named headers, several columns could get
squashed together.
This fix check if a value is a duplicate or not, and if it is a
duplicates postfix an number allowing to differentiate the two headers
(for the human and the javascript).
This is the exact same solution than #6722
Backport of 5cff8fbb7c70a372cb5116c2fb98fd622c4d4358
opw-650000
fields received by the fields_get call sometimes have a digit
precision. This commit makes sure that it is used when
formatting the cells to be displayed.
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
The group_by query expects the context to have group_by_no_leaf = true,
so we can not just blindly forward the context to the groupby query.
This is a defensive way to fix the problem, to avoid other possible
crashes. But the context shouldn't have group_by_no_leaf anyway,
it does not make sense to explicitely do that in the action
the new graph view silently ignored the context when doing its rpc
read_group. Usually, it's not really a problem, which is why it is only
now being fixed, but some models actually use the context in read_group.
(for ex, account_entries_report)
Recently, the graph view was changed to prevent changing groupbys
for active custom filters. Unfortunately, I did not take into account
the fact that pivot table can be drawn in part when expanding rows.
The "frozen" parameter was then undefined and caused display problems,
this patch should fix the issue.
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)
* add a 'total' foldable button to allow the user to control the column
in pivot table view
* in the dropdown menu, add all fields from the model instead of only
those from the search view groupbys
in graph view, when the user click on the pivot table. It was
calculated with pageX, pageY and positioned with 'absolute'. However,
the main view is now also positionod, so the dropdown menu was not
where it should be.
don't redraw the full table when folding rows. instead, it removes from the dom the corresponding rows. This should give a big speed boost when folding rows on big tables.
bzr revid: ged@openerp.com-20140508124002-yaa383rq4c0qhrf8
the rendering code of the pivot table didn't use $ in jquery variables,
this commit fixes that issue and slightly simplify their names.
bzr revid: ged@openerp.com-20140508111311-kargzvzlttutwt47
Previously, it was done in a ugly way: added several spans with the class
.graph_indent. Now, it simply sets the margin of the content.
bzr revid: ged@openerp.com-20140508110027-bdjdzlpfptjuf4fa
The issue was that the get_search_fields method tried to get the view's
corresponding searchview after a rpc (fields_get). Sadly, if the user
had meanwhile clicked again on the menu item, the first view would be
detached from the view manager and would be unable to reach the search
view. The solution is to move the lookup for the search view in the start
method, where it is guaranteed to exist.
bzr revid: ged@openerp.com-20140430084927-m11dxqg9ko0dnu08
The pivot table rendering was slow with large tables : it appended to the
table each line, so the browser had to rerender each time the page. This
was solved by rendering the table to a document fragment, then only add
the fragment to the main document. This speeds up considerably the process
(from 2600ms to 420ms in one test)
Also, uses basic loops instead of underscore maps in the build_rows method
bzr revid: ged@openerp.com-20140430074733-quhfkzz33rlpahps
It was removed a long time ago, but it looks like the 'expand all' button
is useful enough to make a comeback.
Also, this commit removes a few useless lines in graph_widget about the
grouped/stacked status of bar charts
bzr revid: ged@openerp.com-20140428090221-po3ksrd73093w3qm
The graph view is asynchronous when updating data. It is not safe when
the user tries to update quickly the group bys (for example, when adding two
group bys in quick succession).
This patch partially fixes the problem: it makes sure that two concurrent updates
will be correctly serialized. However, it is not a complete fix: the crash can still happen
when three or more updates are quickly done. A complete solution require some more work in
keeping tracks of an update queue and serializing properly the updates. (will be done in trunk)
bzr revid: ged@openerp.com-20140425102501-qe7ve1ug8neq1twv
Nicolas Martinelli
Goffin Simon
kevin wang
Denis Ledoux
Christophe Simonis
David Monjoie
Géry Debongnie
Raphael Collet
qdc
Olivier Dony
Jérome Maes
Gery Debongnie
Kersten Jeremy
Antony Lesuisse
Christophe Simonis