| Age | Commit message (Collapse) | Author |
|---|
|
Fixing missed 'pivot_row_groupby' assigned to groupedBy in pivot_model.js in
Load function (Already done in reload function), which was missed in commit
42f22a2.
Added qunit test case for testing correct value.
Apply pivot_row_groupby on user in project
task-54027
|
|
closes odoo/odoo#32088
Signed-off-by: Christophe Simonis <chs@odoo.com>
|
|
|
|
|
|
|
|
|
|
closes odoo/odoo#31790
Signed-off-by: Christophe Simonis <chs@odoo.com>
|
|
Part of task 1896658
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
Co-authored-by: svs-odoo <svs@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>
|
|
In 11.0 f8b38f64d improved the column group by managment when reloading
several times by having the same "groupbys" dictionaries between the
pivot model instance and the header menu.
This has been reverted in 12.0 (with c6e7adfb95d) because the following
pivot tests failed with the change:
- 'rendering of pivot view with comparison'
- 'export data in excel with comparison'
The failure is because now that the "groupbys" dictionaries are the same
object, the truncated dictionary of a header truncate the one of the
model instance.
So if we search something that has no results, then something with
results, the groupbys could be lost.
This behavior has no reason to be and is changed in 11.0 with #31644,
this commit is the forward-port of f8b38f64d and #31644.
closes #31627
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
|
|
|
|
|
|
|
|
|
|
On a pivot view with a default filter which has column and row groupbys
Remove the filter
Collapse all columns and rows
Activate another Filter from favorite which has a column groupby at least
Before this commit, the columns were not displayed in the DOM, though RPC's
and internal data were actually correct
This was because we considered the changes had been done "in place"
taking the old tree to build the new one for the columns
when really, we should have recomputed the column tree
After this commit, the columns display the group we want
OPW 1935155
closes odoo/odoo#31247
|
|
"Variation" was not translated
opw-1940086
closes odoo/odoo#31050
|
|
Allow the customization of the pivot header cell's left padding in mobile.
Task Id: 1904747
|
|
|
|
Open a pivot view with default filters automatically activating
Disable those filters
Change the groupBys on the rows and cols of the pivot
Save your result as a favorite filter
Before this commit, the filter did not contain the context information for columns groupby
Also, the search view did not exploit the context of the new filter as it should be
After this commit, the flow works as expected
OPW 1913732
closes odoo/odoo#29415
|
|
|
|
|
|
Also contains fixes for previous forward-port.
|
|
|
|
closes odoo/odoo#30045
|
|
|
|
This branch introduces a large-scale reorganization of the
component tree generated by the web client. The short version is
that now, the control panel is a child of the view controller and
no longer a sibling. Graphically (and simplified), we go from
this:
webClient
/ | \
... ... actionManager
/ \
controlPanel viewController
/ \
to this:
webClient
/ | \
... ... actionManager
|
viewController
/ | \
ControlPanelController
/ \
CPRenderer CPModel
The motivation is that this work moves the code where it should be.
Before this commit, it was kind of weird to have code in the
controllers to render buttons outside of their root node (in
renderButtons). Also, the action manager had to take care of
coordinating search view states between view transitions.
So, this work simplifies the code. It also makes it easier to
extend. We see day after day that Odoo needs to take care of more
complex UI needs, and in many cases, these needs were quite
difficult to implement (we prefer spaghettis in our plates, not in
our code). The changes in this branch should open the way to
implement these features.
For example,
- it will now be easy to add the possibility of views (for example,
the search view or a new ControlPanel view) to add custom buttons
(of type action or object) in the control panel.
- Another need will be to serialize/ restore the state of the
search view across action boundaries (needed by the dashboard).
- Another example is the possibility for views to customize easily
the presence/absence of sub menus (filters/groupbys/favorites/
time range/...)
- Another need is an easier way for views/client action to customize
their control panel.
This commit also contains a large rewrite of the search view (so it
is more inline with our architecture and easier to maintain).
Part of task 1893568
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
|
|
Support for string attribute on fields in pivot view was added in 24f7c7ce7f371bb
In some cases, the field is not stored and read_group method is
overridden to allow its use in a pivot view. Such a field does not
appear in the measures dict trying to set the string attribute, leading
to a client crash.
With this commit, the string attribute is set after the non stored
fields were added to the dict.
closes odoo/odoo#29393
|
|
The pivot view may sum fields that are not really summable:
unsigned values (e.g. in the case of refunds)
values in different UOM, currencies (any different units really)
Which causes confusion when these fields are displayed.
We add support for the string and invisible attributes in the pivot view,
so that a field can be given a more informative name or hidden altogether.
opw 1909046
closes odoo/odoo#29144
|
|
Before this commit, it was not possible to sort
the rows of a pivot view while in comparison
mode. This fix makes it now possible. Note that
in comparison mode, a click on a header of type
"measure" will sort the rows according to the
column values coming from the data of interest.
closes odoo/odoo#28411
|
|
|
|
It broke other pivot tests.
closes odoo/odoo#31630
Signed-off-by: Christophe Simonis <chs@odoo.com>
|
|
|
|
|
|
In 187c32c2 some improvements were made for conserving/restoring group
bys on the pivot view.
This introduced an issue on the column group by:
- before reload, if we set manually a column group by (+ icon in the
header) it would be saved and not lost (unless a context or filter
in the search view override it)
- after reload, the following manually set column group by are not saved
anymore on subsequent reload (the column group by at the first reload
are set back)
This behavior is not normal since the behavior (conserving or losing
column group bys) should be the same at first reload or second reload.
The issue was caused by the duplication of group bys that were not
synchronized (one on the column root header, one on the pivot model
instance).
Without the change, the added test failed with: "Column groupby not lost
after second reload" and product_id is hidding from the object
pivot_column_groupby dictionary (having only "customer").
Using _.clone on initialRowGroupBys was necessary change because without
duplication of "groupbys", the initialRowGroupBys would be changed on
expandHeader which is unexpected.
opw-1941095
closes #31407
|
|
(mainly views and ActionManager)
- add missing docstrings
- fix typos
- correctly order functions and imports
- put functions in correct sections
- stop using 'event' as argument of handlers
- don't call handlers directly
- remove trailing spaces/tabs
- move module created in stable version to its own file
- follow js guidelines in general
closes odoo/odoo#28024
|
|
The count measure is now put first in the order
of selected measures.
|
|
In comparison mode, a useless line with an
empty header was sometimes created due to
problem in the treatment of read_group results.
This is no longer the case.
|
|
Menu items for measures list are now sorted by their 'string' value.
We set that string in lowercase because uppercase/lowercase influences
string comparison, so we are sure to compare always strings with the
same case.
This fix is effective for pivot view, cohord view and graph board.
Task #1882576
|
|
|
|
|
|
|
|
This commit fixes a bad behavior of the pivot view. By the
past, if there were no data to present in the pivot view, no
information on the pivot view configuration was returned by
the get function. This does not cause problems to the pivot
renderer (by design) but causes problems elsewhere, for
instance in a dashboard view that contains a pivot view.
Indeed, at each update, the dashboard view reinstantiates its
subviews, so that information can be lost if a subview is of
pivot type.
|
|
The _mergeData function used in pivot view comparison mode
was not designed to accept the absence of the __count key or
null values for measures in the objects returned by a 'read_group'.
The absence of the __count key would result in a traceback and null
values for measures into wrong calculations (infinities).
One could ask why null values did not cause problem before.
The simple reason is that the formatters used to format cell values
render a 'null' value like they render a zero.
This fix makes explicit that null values have to be considered
as zeros and avoid in that way Infinity values when computing
variations.
|
|
Exporting data of a pivot view in comparison mode ends in a
crash. The root cause is that _t was replaced by _lt
so that some strings were replaced by objects with a toString method.
This does not cause problems when rendering a pivot view since
both QWeb or JQuery call that method. The function _exportData does not.
This commit fixes that situation and adds a test of _exportData.
|
|
The buttons 'Flip Axis', 'Expand All', and 'Download xls' are
now deactivated when no data are displayed in the pivot view
(those buttons are useless in that situation).
|
|
The pivot view didn't take into account the widget set on the fields.
In particular this was a problem for float fields that store time values.
They are now displayed with float_time if declared as such in the view.
opw 1876445
|
|
A previous commit [333ac27] has introduced a new widget TimeRangeMenu
that allows to create two sets of data to compare relatively
to a given date or datetime field.
This commit allows the pivot view to render appropriately two
sets of data in a unique table. In comparison mode, instead of
one column, three columns are created. One contains the
aggregates from the data of interest, one contains the
aggregates from the comparison data, and the last one contains
information on the data variation (expressed in percentage).
Task Id: 1835644
|
|
This commit introduces a new widget 'TimeRangeMenu' used in
the search view. It allows a user to easily:
- search data with a given date or datetime field value
in a specified period of time
- compare the data of interest with data of the previous
period or the previous year.
The time range menu is available in the search view when one
of the four following view types is instantiated:
graph, pivot, cohort, or dashboard.
Task Id: 1835644
|
|
מזל טוב
The direction parameter will now have a real impact on the web interface and
completly switch the direction of the interface.
Add the dependency rtlcss to switch the direction with a css postprocessor.
Two different assets will be generated for ltr or rtl
/web/content/<...>/web.assets_backend.0.css
and
/web/content/<...>/rtl/web.assets_backend.0.css
to be able to differentiate it easily
Adapt the css and views to be easier to switch direction
Render graph as it is, do not move y-axis right side, as per mathematical rule
value goes left from origin are considered negative, so keep graph as it is
for right to left language
add test cases for language direction specific assets bundle
if language direction is rtl then we also store css files in assets bundle
now we store two assets bundle, one for ltr and one for rtl language direction
test two assets bundles generated, also test two assets bundle generated for en_US and ar_SY
|
|
|
|
|
