Before this commit: all groupable fields were offered to selection when
a user would click on a suitable pivot header. While guaranteeing maximal
flexibility, this was easily overwhelming to any new commer.
After this commit: when at least one groupby is defined in the search
arch, the selection is done in the search arch groupbys (plus eventually
some custom groupbys) via a menu similar to the "Group By" menu in the
control panel. The advanced users have still access to more options in a
"Add custom group" menu again as in the control panel. When no groupby
is defined in the search arch, the selection is done among the groupable
fields as before.
This has led to a small modification of control_panel_model_extension.js:
it has become necessary to distinguish the groupBy filters coming from
the arch from those created by the user via the "Add custom group" menu.
Task ID: 2376505
closesodoo/odoo#61572
Related: odoo/enterprise#17341
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
PURPOSE
Be able to remove some measures from graph / pivot views. Currently fields
are automatically added but some of them make no sense.
SPECIFICATIONS
Add the possibility to not display some fields in the measures dropdown for
the graph and pivot views.
When a field is not displayed in the measures of a pivot views we remove them
also from the list of groupable fields.
LINKS
Task ID-2288381
Community PR #54774
Enterprise PR odoo/enterprise#11970
Upgrade PR odoo/upgrade#1519
In pivot view, a cell data is determined by his row/column key which
are the value chain of field values to get to that row/column.
If you had a grouping with value in a cell and then close the grouping,
you could somehow get the old value back wrongly on next grouping
operations.
This happened because:
- the key was computed based on the value (eg. for relational field the
record ID) but without the field name.
- succeeding read_group only fill existing values.
eg. If on pivot view we had a salesperson with same ID as product
category, if we closed salesperson grouping then opened product
category grouping, we could possibly get the cell value to the product
category that has the same ID as the salesperson.
With this changeset, we clear the cell data corresponding to a grouping
that has been closed.
Added test without the fix would fail by displaying data of a previous
read_group that should have been cleared inbetween.
opw-2262306
closes#55129closesodoo/odoo#55936
X-original-commit: f1df73adca4955561814d4b8e90a62d7d50c1c33
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Before this commit, click on the divider in the menu 'Measures' of the
pivot control panel would cause a crash. The present commit fixes that
situation.
We also bring another small correction: the menu won't close if one
clicks on the measure list but not exactly on a menu item or the
divider.
closesodoo/odoo#55902
X-original-commit: aad9f3fd7499ef8b660cc25fea840a34d70f75a6
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine <Polymorphe57@users.noreply.github.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Improve mock server:
- add support for mocked `fetch`
- add support for `active_test`
- add support for x2m `in` in domains
- add support for default values computed from a function
- implement a more natural "next id" compute
- allow initial data without ids
- ensure write and x2m commands integrity
- improve bad data/bad commands error messages
- always warn for failing RPC, not only in debug mode
- fix all existing tests that had inconsistency data
Other changes done in mail (or dependents) that are not just related to tests:
- remove `direct_partner` from formatter result
->`correspondent` can be computed from other keys, especially `members`
- fix `livechat_visitor` convertData
-> only process if there is value
- add `current_partner` and `current_user_id` as `init_messaging` result
-> easier to mock than session
- remove usage of `need_moderation`
-> that was just a search indirection to `moderation_status`
- adapt `partner_id` -> `res_partner_id` key in `_notification_format`
-> to be consistent with field name
- add name in result of `mail_partner_format`
-> sometimes display_name is not the same
- remove usage of `is_moderator`
-> that was just an indirection to `moderation_channel_ids`
Enterprise counterpart: https://github.com/odoo/enterprise/pull/11523
task-2287171
closesodoo/odoo#55854
X-original-commit: 7ba3fecb3377a720d1eb70e7515a0c45da73836d
Related: odoo/enterprise#12391
Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>
A previous commit has paved the way for displaying sample data in the
reporting views. The present commit brings the required changes to have
sample data in pivot views.
Task ID: 2282196
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Adaptation of the tests to the changes regarding the refactored search
panel and model.
Part of task 2228968
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
When comparing time ranges in pivot, it makes more sense to display the
previous period before the one being compared. This commit allows that.
Task ID: 2269770
closesodoo/odoo#52746
Signed-off-by: Mathieu Duckerts-Antoine <Polymorphe57@users.noreply.github.com>
Co-authored-by: Priyanka Kakadiya <pka@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
Tests have been adapted accross all affected modules to support the new
"comparison" menu component.
Task ID: 2245719
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
In the pivot view, groups comming from many read_group are assemble
to create the header hierarchies and the table.
Groups returned by the read_group may be already sorted by the server
using the order set on the model for instance and that order should
be reflected in the header hierarchies (and in the table).
It is important to keep that order since it might not be possible
to recreate it in the interface. Even if possible it might not be a
good idea for performance reasons.
Before this commit:
The groups are added in a JS object, whose keys are the group ids
(when grouping on a many2one at least). Then, to generate the table,
we iterate over the keys of that object, but those keys are sorted
according to the numerical order (not the insertion order),
because keys are kind of numeric.
See https://stackoverflow.com/questions/5525795/does-javascript-guarantee-object-property-order.
After this commit:
Instead of a JS object, we use a Map for which the insertion order
is used (official spec).
Task ID: 2243416
closesodoo/odoo#50551
X-original-commit: 1a9a85c8b8d0f47c3c6f3878cd6d9401ddc3ad75
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, some elements in the control panel were not properly encapsulated
in layout-related parent elements and this caused some inconsistencies if some of
the control panel components were not displayed. For example: if the breadrumbs
were missing, the search bar went to the left side instead of the right.
Now, all components are in a grid-like structure (in desktop mode) and should not
overstep their given boundaries. The layout in mobile remains unchanged since the
top part behaves quite differently.
closesodoo/odoo#50057
X-original-commit: 533db5991a5bb871198485cd71a63f75a8c6becf
Related: odoo/enterprise#10148
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>
Use of the new control panel helpers to increase consistency and change the assertions
according to the new DOM/behaviour (e.g. components removed instead of turning invisible).
Part of task 2196029
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Since formatBoolean returns a jQuery object, boolean fields were
displayed as [Object object] in pivot view.
so fix the issue of checkbox in the pivot view by not calling
fromatValue for boolean instead just set the checkbox element in
in template itself and added test case for checkbox in pivot view.
closes odoo/odoo#46445
Taskid: 2172258
Closes: #44299
X-original-commit: d7d0caf6f599f313687c958c5aff5764c0d23ffd
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>
before this commit: if only one measure is enabled then measure row not
displayed in downloaded xlsx file
after this commit: downloaded xlsx file will always have measure row
either single measure enabled or multiple measure enabled
task-2127388
closesodoo/odoo#40769
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
before this commit: file was downloaded in xls format, which supports
maximum 256 columns and 65536 rows.
after this commit: pivot returns xlsx file when table printed and
downloaded, we have support of xlsxwriter, xlsx file supports 16384
columns and 1048576 rows
task-2127388
This commit changes ControllerAdapter to a mixin that inherits
WidgetAdapterMixin and RendererWrapper now extends ComponentWrapper.
This commit also changes PivotController base class/mixin and uses
the Odoo legacy custom_events because of the adapter.
closesodoo/odoo#43256
Related: odoo/enterprise#7744
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Because the webclient and other higher level components such as the
actionManager are not yet rewritten in OWL, we cannot make a complete
migration of the controller and the model to a more OWL-ish code.
We have rewritten the renderer completely in OWL, it uses more
extensively a template and manages its own state and its sub-components.
We did not rewrite the controller, however we have made it inherit from
`web.ControllerAdapter` which is a thin compatibility layer used when a
odoo controller uses a OWL renderer.
In the tests, the only changes are that all the events triggered by the
test and handled by OWL must be triggered on DOM nodes directly and not
on JQuery elements.
closesodoo/odoo#39491
Related: odoo/enterprise#7135
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Co-authored-by: VincentSchippefilt <vsc@odoo.com>
Co-authored-by: pro-odoo <pro@odoo.com>
In this commit:
- transformed test_utils helpers to always trigger native events
- introduced new test_utils_create helper: prepareTarget
- updated qunit asserts to support Owl Components
- updated all misused helpers that would crash with the updated test_utils
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Pierre Rousseau <pro@odoo.com>
Before this commit, with a time range activated in a pivot view,
click on a non empty cell would not always give the right list of
records because of a bad action domain.
The reason is that the headers domain or comparisonDomain were
not always set when appropriate:
- for the headers 'Total', the corresponding group obtained
by read_group does not contain the key __domain. For that
reason both the key domain and comparisonDomain were left
undefined.
- for headers that correspond to groups not present in the two
periods compared, one of the key was left undefined.
With the present commit, we correctly set the domain and
comparisonDomain keys everytime they are useful.
closesodoo/odoo#40713
X-original-commit: 2f89820faa5966b8321d6681e9745a4e938e2bec
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The main aim of the present refactoring is twofold:
- simplify the code that was largely complexified at the time of the
introduction of comparisons in the pivot view (Time Ranges menu),
- factorize the method expandHeader and _loadData that were too much complex.
Along the way, the pivot model structure has been simplified
and many tests have been added.
Performances in mobile mode have been improved by avoiding
unecessary operations due to useless column groupbys in that
mode.
It should now be easier to understand and modify the pivot view in future.
Co-Authored-By: Aaron Bohy <aab@odoo.com>
closesodoo/odoo#33615
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Open a pivot view, make a search for some field
Click on a pivot cell to display the list view of elements matching the group's domain
Go back to the pivot using breadcrumbs
Before this commit, the original search domain was not kept across those actions
After this commit, it is kept
This difference is due to the fact that before 12.2, the whole action had an env, containing the search domain
in 12.2 and afterwards, things are not done this way anymore
OPW 2030555
OPW 2030983
closesodoo/odoo#35096
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
In case a many2one field (let us say 'foo') is used
simultaneously as a groupby and a measure in the pivot view,
the values returned by a read_group for that many2one are of
the form [id, label] and the aggregated values (always 1) are
missing in the read_group results (datapoints).
Thus typically, a datapoint is of the form
{'foo': [1, 'Bar'], '__count': 4, ...}
and does not contain information on the 'foo:count_distinct'
value (this is a read_group bug).
As a consequence, a special processing of the read_group
datapoints is done in the pivot model to handle that
situation and the value for 'foo:count_distinct' is infered
correctly to be 1.
In the pivot comparison mode, datapoints comming from the
period and the comparison period (data and comparisonData
sets) are identified if they have same values for the groupby
fields and the measure values become small objects containing
information on the the measure values for data and for
comparisonData and on the related variation.
Thus
{foo: [1, 'Bar'], __count: 4, ...}
from data and
{foo: [1, 'Bar'], __count: 3, ...}
from comparisonData should become a single datapoint
{
foo: [1, 'Bar'],
__count: {
data: 4,
comparisonData: 3,
variation: {
magnitude: +33 (%)
}
}
fooAggregate: {
data: 1,
comparisonData: 1,
variation: {
magnitude: 0 (%)
}
}
It turns out that the code responsible for merging the data
and comparison datapoints made a mistake by mixing the keys
'foo' and 'fooAggregate', with the consequence that the
variations were not correctly computed in the situation
described above.
This is fixed in this commit.
closesodoo/odoo#33118
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
After a recent reorganization of the web client's components tree, the
class 'o_enable_linking' was added on the wrong element. This made the
css rule responsible of the highlighting of the clickable pivot cells
impossible to satisfy.
This commit fixes the issue by adding the class directly in the template
'PivotView'.
Additionally, this commit also makes visually clear when a field
selection menu-items is disabled (because it is already used) using
a 'not-allowed' cursor (which was removed in bs4). It is now again
possible to open a list view by clicking on a cell with zero value
(like in Odoo 11).
task-1916889
closesodoo/odoo#34165
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
The old tree views don't really exist anymore, this odd pseudo-flag to
dispatch between "list" and "tree" tree views has no reason to remain.
Task 1937686
closesodoo/odoo#31243
Signed-off-by: Xavier Morel (xmo) <xmo@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 c6e7adfb95) 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
closesodoo/odoo#31247
On a view, define a timerange for fetching data
Save as favorite
Before this commit, the time range description were not transmitted as
strings for the creation of the filter
So, when loading the filter back, there was no description for column headers
resulting in displaying "Object [Object]" as their title
After this commit, we save in the context of the filter the description of the title
OPW 1930582
closesodoo/odoo#30992
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
closesodoo/odoo#29415
