| Age | Commit message (Collapse) | Author |
|---|
|
This commit is a split of the former graphview into a pivot view (the
tabular view) and graph view (the various charts). The code was fully
rewritten.
* pivot view should be faster (better underlying data structure and
better algorithm)
* better integration with the web client (use of sidebar, of menu buttons,
bettor style)
* new feature: pivot view can be sorted
* new feature: pivot view cells can be clicked to open a list view with
the corresponding domain
* web_graph addon was removed, and the graph view code has been moved
to the addon web.
* the interaction with the searchbar was changed (no more column facet)
* better and simpler code for graph view
* mary corner cases in graph charts have been corrected (for ex, pie
chart with positive and negative numbers)
* graph/pivot correctly save their state when added to dashboard/saved
(state such as current measure, chart mode, column groupbys, ...)
|
|
|
|
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
|
|
|
|
|
|
It was wrong.
|
|
|
|
|
|
XLWT only accepts sheet names smaller than 31 characters because that's the
excel limit.
Fixes #2548
Fixes #3318
|
|
|
|
|
|
|
|
mostly styling, and related micro-changes
|
|
|
|
notable: disable the group by integration in graph view, because of crash (the search view was rewritten and too much search logic was in the graph view. This is a temporary measure, the graph view will be split into pivot/graph views, and the search integration will be done correctly in the near future.
|
|
|
|
the views don't always return a proper promise, or were
somewhat fragile and broke with the changes in the view
manager.
|
|
|
|
|
|
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
|
|
|
|
server: rev. 26 rev-id launchpad_translations_on_behalf_of_openerp-20140923072744-tkfs0yinu8msjh09
addons: rev. 39 rev-id launchpad_translations_on_behalf_of_openerp-20140923072715-5j7qvnuvmmb1zzy1
web: rev. 23 rev-id launchpad_translations_on_behalf_of_openerp-20140923072757-jvh9l6r2x0vfcyhb
|
|
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)
|
|
|
|
|
|
|
|
The field selection menu was not positioned correctly when there was
a long list. (was not displayed at the position clicked)
|
|
|
|
|
|
|
|
|
|
graph view
|
|
|
|
|
|
|
|
to prevent possible future conflicts
|
|
* 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
|
|
Non stored functional fields cannot be grouped by read_group, so it is
useless, and even harmful, to display them in the measure list (in
graph view).
|
|
|
|
Also, removes an old TODO.txt that was completely outdated.
|
|
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.
|
|
searchview has been split in two parts, and the inputs are now located
in the drawer
|
|
|
|
This patch makes the graph widget only add the rows that were new instead
of redrawing the full table when expanding
bzr revid: ged@openerp.com-20140509090935-sje3u6i4x1luswwn
|
|
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 code was bugged: it added a <tbody> tag around each rows instead of adding the rows to a single tbody.
bzr revid: ged@openerp.com-20140508112723-b6ffkmufwux1z0a7
|
|
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
|
