Before this commit, if there were several facets in the search bar, it
was not possible to navigate correctly between them.
closesodoo/odoo#93547
X-original-commit: d2b6aab509717866ab42a9750adbb884ccec18a4
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
It is now possible to get access to the action context keys when the
search filters are evaluated. This means that a search arch filter like
<filter name="my_filter" domain="[('my_field', '=', context.get("my_value))]"/>
can be safely evaluated if "my_value" is in the action context (or in
the user context or is builtin as before).
closesodoo/odoo#91959
Signed-off-by: Géry Debongnie <ged@odoo.com>
A server action sometimes returns an action with a help key.
That help was not marked up, leading to an incorrect display of that help.
closesodoo/odoo#86170
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The method call_button sometimes returns an action with a help key.
That help was not marked up, leading to an incorrect display of that help.
closesodoo/odoo#84869
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Chart.js did badly compute the graph canvas container height (width) by
using clientHeight (resp. clientWidth) that may be rounded up by the
browser. This leads to the appearence of a useless scrollbar in the
graph view and makes it flicker on some update.
closesodoo/odoo#84476
X-original-commit: 6bceae94619da9f4943cbc1e58844fdbe0215802
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
We bring two changes to the API of useAutofocus:
- it takes no parameter, the element focused is the one that is the
target of a t-ref="autofocus".
- it returns the element reference instead of a function to call if
one wants to force the focus on a next patch.
Indeed, having access to the element reference makes it easy to focus
that element but also allow to remove an eventual useRef that would
target the same element. This in turn permits the use of t-ref="autofocus"
alone.
closesodoo/odoo#84306
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In 6d13271aac, the API of useAutofocus was chanded but the calls to
useAutofocus in the module point_of_sale were not adapted accordingly.
We adapt them in this commit.
Part-of: odoo/odoo#84306
In preparation for OWL-2, we introduce a new tooltip service that replaces
the hook useTooltip used by the webclient. The main reason for that is
that the implementation of useTooltip had to access el on the components
calling it. Since this won't be possible anymore in OWL-2 (el is ill-defined
in presence of multi root components) we had to find something else.
Another reason is that the useTooltip hook had no reason at all to be a
hook (as attested by the fact that only the webclient needs to call it
to have tooltip on every dom elements).
closesodoo/odoo#84160
Related: odoo/enterprise#24152
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
OWL-2 is in preparation and will be soon merged. One of the changes it
will bring is that it will be no longer possible to use the directive
t-ref on a tag component. Here we refactor the code in order to remove
two uses of such t-refs.
closesodoo/odoo#81984
Related: odoo/enterprise#23464
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
OWL-2 is in preparation and will be soon merged. One of the changes it
will bring is that it will be no longer possible to use the directive
t-on on a tag component. Here we refactor the code in order to remove
one use of it in the action service.
Part-of: odoo/odoo#81984
Before this commit, in a line chart in comparison mode with one groupby,
if only data comming from the comparison period were displayed, the line
(with red border) would be filled incorrectly with a blue color while it
was not supposed to be filled at all (the blue filling is supposed to be
reserved to data comming from the reference period).
closesodoo/odoo#82577
Forward-port-of: https://github.com/odoo/odoo/commit/6747d982a56af0525cf52732c43351081831d32f
X-original-commit: 519e205a4b34fdecfe6b938ff4a6e93a02c2bda2
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In the graph view in line mode, fake data are added when there is few
data to center the graph (the points in facts). Now, there
are two problems with the relabelling of the labels created along with the
fake data:
- the relabelling (when it works) gives "Total" instead of "" (nothing)
- the relabelling crashes when the line chart is grouped by a date
field, a comparison is done on that field and no data is received.
We fix the problem by introducing a custom label similar to NO_DATA
(a custom label used to manipulate fake data in the pie charts).
Forward-port-of: https://github.com/odoo/odoo/commit/a30669d1ff258e3ac71dff4d78ca295aa1be2ec8
X-original-commit: 6374618e4d201a53182c6adf2127b0e64b4e48d1
Part-of: odoo/odoo#82577
Since the refactoring of the views aeb8e49972f871b0c9b07c507987ee77cf5e8abbd,
the filters and date filters, the groupbys and date groupbys are now
always separated visually even if no separator/group tag has been
set in the search arch. We restablish the previous behavior that only
seperates them when a separator/group is set.
closesodoo/odoo#82418
X-original-commit: e281bd0850e935ce0d97226366114da4f5406c4d
Signed-off-by: Samuel Degueldre <sad@odoo.com>
Before this commit, an action group_by like "subscription_id" was accepted
in production mode but would make crash a view that uses the WithSearch
component as soon as the dev mode is activated. Here we fix the
problem by making the acion service process the action group_by in order
to make it pass the validation.
closesodoo/odoo#81306
X-original-commit: ea209f126c57ea2f3e456a9b459dd46fd78fc33a
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Load an action with a list view with at least one record and open the
view form for a record. Then reload the page and go back in the breadcrumbs.
In desktop mode, one arrives at a list view again.
Before this commit, the search view was not correctly initialized.
The problem was that the list view reuse a globaState prepared by the
form view that contains a search model state that do not reflect the
search view arch (the form view does not use the search view).
We fix that problem by preventing the form view to install the
ControlPanelModelExtension. In that way, the form view does not export
a search model state in the globalState and the list view correctly
process the search view arch.
Task ID: 2697084
X-original-commit: 40e04695ef0de96df8b850fac3f7d165585d466a
Part-of: odoo/odoo#81306
Before this commit, when comparing a period P of reference to another one,
some rows with only data comming from P would not always be presented
in the table. The problem used to manifest only when loading at least to
level at the same time (starting from Total or any header via expand all).
The reason is the following:
- the data comming from P are processed first: starting from somewhere
in the trees of headers, some nodes linked to the data comming from P
are progressively created with no children at first, then the children
(if any) are added later and so on progressively.
- the data comming from the other period is processed and nodes are
created with no children and so on in the same way, clearing possibly
all the node children comming from P.
For example, with
a row groupby = [field_a, field_b],
a group [v, v1] from P
a group [v, v2] from the other period,
a node corresponding to v would be added, then a node child for v1.
Then the node for v would be recreated with no children, then a node child
for v2 would be created. leading to a tree of row headers of the form
Total > v > v2.
Note that it was not affecting the measure values for the displayed rows
since those measures are stored separately from the tree and are linked
to the nodes via some ids.
We fix the problem by avoiding the recreation of a node if it already
exists.
opw-2635113
closesodoo/odoo#80468
X-original-commit: 364475b5da3d4aaa87db715f0c0bbaa9dd3e05c8
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Andrea Grazioso <agr@odoo.com>
The commit 3862d5aae1df72d3585f915e8a2a2626322e74ad has changed the class
set on the root node of the graph renderer but has not adapted a css rule
used in the board app to ensure that the graph views have the correct
height. We fix that situation.
closesodoo/odoo#80047
X-original-commit: b08bc57d5ba2e0da17a452189d584574fb2f9832
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Since 40f1ae87e1436192a70a8a7432eb72d379cfa6dc, a view added to the board application would not
have the correct domain:
- the action domain was not kept in the saved domain
- the saved domain was kept dynamic, leading to possible crashes
e.g. a condition like ("user_id", "=", uid) in the saved domain
would make crash the dashboard app.
We fix the problem and add a test.
X-original-commit: 7e77bb74bfa1bfef92c6d385dedc2d89e0040780
Part-of: odoo/odoo#80047
During the refactoring of the legacy control panel done in d679cd0d8ba9a2420e81a42a698763e9be2327e1,
the method "_addToBoard" was renamed as "addToBoard", but a call to _addToBoard
was left, breaking the keyboard navigation. We fix that situation.
X-original-commit: 6aa10e8c9118eba3c19563431c57912108fe12b9
Part-of: odoo/odoo#80047
The identification of timedelta with relativedelta was wrong.
Here we define a class PyTimeDelta used by py.js to evaluate most
expressions in which datetime.timedelta and some operations producing
timedeltas occur.
The class PyTimeDelta allows to:
- create a timedelta
- add/substract two timedeltas
- multiply (divide) a timedelta by a float (resp. an integer);
- take opposite of a timedelta
- evaluate equalities between timedeltas and other expressions
- decide when a timedelta is "false"
- get total_seconds of a timedelta
In relation with that, we have improved the implementation of PyDate
and PyDateTime to allow most manipulations of datetime.date and
datetime.datetime producing/using timedeltas. It is now also possible to
evaluate equalities between dates/datetimes and other objects.
closesodoo/odoo#77453
X-original-commit: fcd4959a65a92e34ce986575c7fc279c195e9a11
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Mathieu Duckerts-Antoine <Polymorphe57@users.noreply.github.com>
The fix ff28db335fa77dadc did introduce some differences in the way
forecast filters work for a legacy or a new view. For example, let us
assume we have two filters F1 and F2 active in the same group with F2 a
forecast filter. In that situation, a legacy view would load with
domain = F1 domain AND F2 domain, and a new view would load with
domain = F1 domain OR F2 domain.
In the present commit, we harmonize the behaviors of ForecastModelExtension
and ForecastSearchModel as much as possible. We also make ForecastModelExtension
use a state received when it loads for the first time.
We have also taken the opportunity to normalize the states of the
extensions: it was not necessary to memorize forecastField (constant)
and forecastFilter (determined by the rest of the state).
closesodoo/odoo#77159
X-original-commit: 37aeb048c286f2f1a78370213635341c32ea621b
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
current_date was absent from py_builtin. For that reason, it was
impossible for the search model to evaluate a dynamic domains like
"[('date_deadline', '<', current_date)]"
We add current_date to py_builtin.
closesodoo/odoo#77035
X-original-commit: ade082c5ad9221c82de90ddbe68b814b1487753d
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
The class PyDateTime did not have a method to_utc. For that reason, it was
impossible for the search model to evaluate a dynamic domains like
"[('date', '>=', (datetime.datetime.combine(context_today(), datetime.time(0,0,0)).to_utc()))]"
We implement that method.
X-original-commit: 3ad9a3be64da78d596ee3dc435d4b224728a9e76
Part-of: odoo/odoo#77035
In order to be able to easily patch Date in py_date_tests and elsewhere,
we refactor the code of the legacy and new patchDate functions.
X-original-commit: 0e697c82be80cae9cc993b4be179fec42b8dae83
Part-of: odoo/odoo#77035
This commit deploys some of the new OWL infrastructure services to the
legacy OWL environment.
The deployed services are the UI and hotkey ones.
These are needed because they are the only prerequisites for the new <Dropdown/>
component to get instanciated with the legacy OWL environment.
As the new reporting views infrastructure has been merged (see odoo/odoo#73311),
the current Odoo version is in a state where some views uses the new
infrastructure and some others are still not converted.
So instanciating the new <Dropdown/> component in the legacy OWL env is
something we chose to do in order to get consistent within the control
panel dropdowns behaviors.
X-original-commit: 6f1ab1cd861549484f94a8d40a16ccf338d7dffe
Part-of: odoo/odoo#77001
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
After the conversion of the graph and pivot views done in https://github.com/odoo/odoo/pull/73311,
it was no more possible to open the forecast_graph and forecast_pivot views.
This is due to the fact that the new View component cannot manage a legacy
view: every extension of a converted view must be converted. We thus
convert forecast_graph and forecast_pivot.
closesodoo/odoo#76793
X-original-commit: ff28db335fa77dadc3198e754f1e0649811fba7b
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The classes PyDate, PyDateTime, and PyTime used in py.js to evaluate
python expressions did not have a toJSON method. As a consequence, the
dynamic domains manipulating date/datetime but forgetting to use strftime
didn't work anymore. This fix simply defines a toJSON method in the three
above mentionned classes
closesodoo/odoo#76699
X-original-commit: 53eefe36f39e6c9ad355e78bcabbba4e0039aa35
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Signed-off-by: Mathieu Duckerts-Antoine <Polymorphe57@users.noreply.github.com>
Co-authored-by: Michael Mattiello <mcm@odoo.com>
The fix 18ea11c99a7e2bd58d7469927352587cb14c76c4 incorrectly set the rule
o_control_panel .o_cp_bottom_left { display: inline-block } to fix a
problem with the graph view buttons in mobile mode: the graph view has
many buttons and they were put on the same line pushing the view switcher
far too rigth. But the above rule had some other unexpected effects.
For example, an action menu button was put incorrectly on an different line
from the button line. Here we simply fix the css rules that regulate on witch line
the control panel buttons are put and their spacing.
closesodoo/odoo#76620
X-original-commit: 1e308b270b6b1f6612b256db35b188bd0a2f5493
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The search param "domains" of type Array was not satisfactory for
several reasons:
- useless for non reporting views
- too close from the search param "domain"
- a key "fieldName" was put on the value (resulting in a loss of
information in case of stringification)
We change it for a search param "comparison" of type null or Object.
closesodoo/odoo#76340
X-original-commit: 4f867099846c4214a74a7b0222ac0941537bbe29
Related: odoo/enterprise#20772
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
During the refactoring of the project_graph and project_pivot views,
their static key "components" were incorectly set making impossible for
OWL to render them. This is now fixed.
closesodoo/odoo#76065
Related: odoo/enterprise#20647
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
We clean various graph archs taking into consideration that:
- the default type of a graph is "bar".
- a bar chart is by default stacked.
- the field attributes type="row" and type="col" does not make sense for
a graph view (since its implementation was separated from the pivot
implementation a long time ago))
- the boolean attributes should now take 1 or 0 as value (but the other
values are accepted for retrocompatibility).
Part-of: odoo/odoo#76065
The reporting views are going to be converted to OWL so that their extensions
(like the project_graph and project_pivot views) have to be converted too.
We thus need an owl version of the ProjectControlPanel class.
Here we introduce that control panel and refactor a bit the legacy code.
Part-of: odoo/odoo#73311
Both "__count__" and "__count" can be encountered as measure notations
in reporting views. Typically, "__count__" is used in legacy views and
"__count" in new views. The problem is that both can now be found on
legacy or new side (think of favorite contexts for example). It is thus
necessary to write some compatibility code on each side. Here me
introduce an helper to help in that task.
Part-of: odoo/odoo#73311
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
We refactor the action service and allow the legacy and new views to share
a global state within a same action.
We introduce two new components View and WithSearch along with
the search infrastructure: ControlPanel, FilterMenu,...
Part-of: odoo/odoo#73311
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Géry Debongnie <ged@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Michaël Mattiello <mcm@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
Co-authored-by: Stefano Rigano <sri@odoo.com>
Before this commit readGroup was actually calling web_read_group.
With this commit, readGroup calls read_group, and webReadGroup
calls web_read_group, as expected.
Part-of: odoo/odoo#73311
Reintroduce the SampleServer class with some modifications:
- it uses luxon instead of moment
- it uses the registry from core folder instead of a dedicated one
A util function is also provided to help the construction of a fake orm
using the sample server in order to get sample data.
Part-of: odoo/odoo#73311
Co-authored-by: Samuel Degueldre <sad@odoo.com>
Co-authored-by: Lucas Perais (lpe) <lpe@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Jorge Pinna Puissant <jpp@odoo.com>
We introduce here an incomplete implementation of the new ControlPanel.
The idea is to allow the rewritting of the client actions that do not
use the search view but only the breadcrumbs or the button zone...
The full implementation of the new ControlPanel will be merged when the
new search infrastructure is ready to be merged.
closesodoo/odoo#75083
Related: odoo/enterprise#20231
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
We prepare the rewritting of the search components for the new weclient:
we rename some legacy templates to allow the new components to use the
natural template names.
Before this commit, the confirmation dialogs displayed by the new dialog
service had the size "modal-lg" (default set on the Dialog class).
We set their size to "modal-md".
Before this commit, click on "Schedule activity" in the activity view
would open a dialog in which the search view is the default one on the
current activity view model.
With this commit, we make the dialog use the same search view as the
activity view.
Done to help with the task 2502339
closesodoo/odoo#73697
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit the doAction method of the action_service did not support
to pass props directly to the Component. Only a few ad-hoc options were passed though.
After this commit, doAction can take a key "props" in options, that will be passed to the Component
(a View or a ClientAction)
the new API becomes
```ts
interface Options {
props: { [key: string]: any };
...
}
doAction(action: ActionRequest, options: Options);
Note that some props (like withFilters) are set by the action service
and cannot be set via the key "props".
Alongside the change mentioned above, we take the opportunity to align the
terminology used in action service to the one used server side: we know use
the terms resModel, resId, and resIds instead of model, recordId, and recordIds.
```
closesodoo/odoo#72397
Related: odoo/enterprise#19127
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Lucas Perais <lpe@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Before this commit, if the loading of a js or a css asset would fail
(via useAssets), a traceback with an incorrect message would appear.
This was due to the fact that a promise was rejected with an event as
parameter. We correct this by rejecting the promise with a custom error.
closesodoo-dev/odoo#960
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The behavior of some components like the Dropdown component depends on the ui service that records
(among other things) what is the "active" element in the page. For instance a dropdown can close/stays open under
certain circumstances if it is in the active element or not. The fake ui service created by makeFakeUIService
was not managing properly the active element. Since we want to avoid code duplication and that there was no real
need for a fake ui serice, we simply drop the helper makeFakeUIService and use the real ui service everywhere.
Writting tests in which input/select elements are involved can become quickly cumbersome
when some external libraries are used somewhere to interact with/manage them. Indeed, change some
input/select value normally triggers some event of a precise form and this has to be properly mocked
in the tests if one expect the libraries to react properly.
The present commit reintroduces the old helper "triggerEvent" (and its generalization "triggerEvents")
that should help in that kind of task.
closesodoo-dev/odoo#887
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
The present commit reintroduces several number parsers that were previously defined in web.field_utils:
parseFloatTime, parseInteger, parseMonetary, and parsePercentage. Some minor simplifications in their API
have been brought. Notably, the "field" parameter has been removed. Indeed, we expect those parsers
to be used in more specific contexts than before so that the advantage of having a common API (value, field, options)
has become less important.
Before this commit, select the "No" option of a boolean field in the
search bar autocompletion menu would crash.
closesodoo/odoo#66058
X-original-commit: ad5d642c455d3215857f25e0d69c593324178d29
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Introduced a function that awaits for an additionnal rendering frame
initiated by the Owl compatibility layer processing.
By default a simple "nextTick" will handle the rendering of any widget/
component stuctures having at most 1 switch between the type of
entities (Component > Widget or Widget > Component). However more time
must be spent rendering in case we have additionnal switches. In such
cases this function must be used (1 call for each additionnal switch)
since it will be removed along with the compatiblity layer once the
framework has been entirely converted, and using this helper will make
it easier to wipe it from the code base.
Some graph view attributes are no longer supported.
We clean the graph_view.rng file and adapt few xml files.
closesodoo/odoo#59513
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
For the graph views based on reporting models (e.g sale.report), click
on a group in the chart redirects the user to an "empty" list view. Here
we use the attribute disable_linking to avoid that redirection for those
views.
Task ID: 2336960
closesodoo/odoo#57622
X-original-commit: 0b0ae92b6bdac25843ba24d767dbcab3b75703e5
Related: odoo/enterprise#13192
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
We order the 'Apps' search panel values by 'sequence'.
Partial realization of Task 2001615
closesodoo/odoo#55997
Signed-off-by: Julien Mougenot (jum) <jum@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>
The attribute 'sample' is now also available for the reporting views
(the cohort, dashboard, graph, and pivot views). Here, we simply extend
the existing doc on the attribute.
Task ID: 2282196
A previous commit has paved the way for displaying sample data in the
reporting views. The present commit brings the required changes in
community to have sample data in dashboard views.
Task ID: 2282196
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@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 graph views.
Task ID: 2282196
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
The present commit brings the global changes necessary to have sample
data in the reporting views. This includes several modifications/
fixes of the sample server (many of them for better visual results).
Task ID: 2282196
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
During the refactoring of the control panel (https://github.com/odoo/odoo/pull/41268)
a regression concerning the operator used for the fields set as
search_default was introduced: the default operator was fixed to '='
while it would have been necessary to take into consideration the
optional 'operator' attribute or the field types. Moreover, the default
operator associated to many2one fields when using autocompletion was
also mistakenly set to 'ilike' instead of '='. The present commit
restores the previous behavior.
closesodoo/odoo#55099
X-original-commit: 1f8e93fc590a6c7ef6b93953058f2dcd643ac620
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
In the search panel, the categories, i.e. fields select="one",
with attributes expand="0", and enable_counters="0" (defaults) were not
correctly updated when the domain outside of the search panel was
updated. This is no longer the case.
closesodoo/odoo#54040
X-original-commit: 99e9cac63f5034c1ba2154779fe82170dd656236
Related: odoo/enterprise#11642
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Problem:
Go to the application apps, select accounting in the search panel,
then filter on lunch in the search bar: the category all is displayed
as selected in the search panel (accounting is no more a valid value
since expand="0") but the application lunch does not appear in the
kanban view.
Root cause:
The kanban model is reloaded with the old domain using accounting
without waiting the search panel to be reloaded but it is only known
after the search panel has been reloaded that the accounting value is no
more valid and that all should be selected instead of accounting, thus
that the domain used by the kanban model should be updated.
Solution:
The solution to the problem is simple: first reload the search panel,
then reload the view model with the updated domain.
X-original-commit: 8589babcd0f2c15433fe1eb06d0d745e80d01c22
In saas-13.3, time range descriptions of a reporting view in comparison
mode were not correctly saved when adding the view to the Dashboard app.
This is no more the case (the bug has been corrected with the
introduction of the comparison menu). The present commit simply
consists in the forwart port of two (adatpted) tests of the original
commit.
closesodoo/odoo#54010
X-original-commit: 9f246a7d8f45203f7b0a9111c0ffd381b5e09052
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The page with the documentation on all js docstrings is regularly
broken. We remove here the link referencing it.
closesodoo/odoo#53911
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The on_attach_callback methods on the widgets (comming from a tag
'widget') of a form renderer were not called at an appropriate time.
They were not called at all or called before the widgets were actually
in the dom. This was made manifest in the dashboards that generally use
pie charts widgets. Each time a pie chart widget is renderered,
a new canvas with a unique id is created. The above mentioned problem
explains why Chart.js was not able to acquire the canvas contexts: they
are obtained by looking for a specific id in the dom.
The present commit fixes that problem by doing in the class FormRenderer
what was already done correctly in the child class DashboardRenderer and
remove the unapropriate calls to on_attach_callback in _renderWidget.
Task ID: 2278717
closesodoo/odoo#53853
X-original-commit: 7641c7074616b4375f1eb4f1fcb5a96e2ed39f94
Related: odoo/enterprise#11537
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
The counters for categories were not updated when filter values were
selected. This commit fixes that situation.
This might impact the global performances of the search panel but
there is still room for improvement. Actually, it could be
possible to reload categories and filters less often by carefully
track the internal changes and the categories/filters attributes
(enable counters, expand,...).
closesodoo/odoo#49307
Related: odoo/enterprise#9795
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
In the search panel, the domain used to compute the field image values
(when the attribute expand is false) was the same as the domain used
to compute counters (if enabled). The idea was that a value bringing an
empty domain is totally useless and should not displayed.
That being true, it turns out that if one does not allow them and
several fields are used, selecting a value in the search panel will very
often totally transform the search panel. From a UI perspective,
this turns out to be bad: the search panel 'moves'.
Let us give an example:
Let us start from a search panel that looks like to:
first_field
A 1
B 3
second_field
C 1
D 2 <--- mouse above D
E 1
with first_field and second_field both with expand="0" and
enable_counters="1". Let us also assume that no record in the global
domain has both first_field=A and second_field=D.
Click on D would make the search panel look like to something like
first_field
B 1
second_field
C 1
D 2
E 1 <--- mouse here
(the selection of D does not impact the values for the second_field but
does for the other first_field values).
This has led us to use basically only the domain comming from
outside of the search panel to compute field image values.
This means that we might now have value with zero count even if expand
is false. In the above situation, a click on D would give us
first_field
A
B 1
second_field
C 1
D 2 <--- mouse still above D
E 1
Task ID: 2154749
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
This commit introduces a new attribute 'limit' for search panel fields
that allows to avoid performance issues. That integer attribute (with
default 200) allows to fix a maximal number of values to display for the
fields. When the number of field values to display reaches the limit,
no values will be displayed. Instead, a warning message will be shown
in the corresponding search panel section.
Note it is possible to have no limit using limit="0" on a field.
This commit reintroduces in a better way the principle brought by the
fix 8d57153b34c04952a85f6642951cb2697016da84.
Task ID: 2154749
The commit introduces two new attributes for search panel fields:
- hierarchize: boolean attribute (default True) available for
many2one fields with select="one". It allows to choose whether
to hierarchize the field values using the _parent_name (if set)
on the field comodel.
Note that a sanitization of the parent hierarchy takes place.
Basically, it ensures that parent chains are
completely in the domain (on comodel) accessible by the user.
See _search_panel_sanitized_parent_hierarchy documentation for
more information.
- expand: boolean attribute (default False) available for many2one
and many2many fields. If set to true, all field values are fetched
and displayed in the search panel. If set to false, only the
values that have at least one corresponding value in the field
model (and in some domain) are fetched.
An exception in the case of an hierarchized field
(hierarchize=True and _parent_name set): more/less values can be
displayed in order to have a good representation of the parent
hierarchy. That means we complete and sanitize the set of initial
field image values.
Note that the fix 8d57153b34c04952a85f6642951cb2697016da84 bringing the
notion of limit in search panel has been reverted in the present commit.
An upcomming commit will reintroduce the limit principle in a better way.
Task ID: 2154749
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
The entries comming from the optional parameter 'mapping' passed at the
instantiation of a registry were never considered when returning the
registry keys or entries. This is no longer the case.
closesodoo/odoo#52768
X-original-commit: e094ddd0ffaf3357e64ca5941ffc2e0454c24ab7
Signed-off-by: Géry Debongnie (ged) <ged@openerp.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>
The control panel test helpers related to the "time range" menu have
been removed and a new helper for the "comparison" menu has been added.
Task ID: 2245719
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
The "board" module has been adapted accordingly to the recently
introduced comparison menu.
Task ID: 2245719
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
This commit replaces the "time range menu" in the control panel by a new
component: the "comparison menu".
Its purpose is roughly the same: compare a period of data in a reporting
view with the previous period or the previous year.
Its implementation is a bit simpler: it will only appear if at least one
date filter is selected in the search view, and will suggest to compare
each selected date option with the previous period or the previous year.
Task ID: 2245719
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
Record counts are now also available for field with select="one"
attribute. In the module account, the counts should not be displayed
since the search panels have to be quite thin. We then disable them.
closesodoo/odoo#44490
Related: odoo/enterprise#8113
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
This commit introduces several changes in the search panel with
respect to record counts:
- the record counts are now also available for
the fields with select="one" attribute
(if not disabled explicitely).
- the record counts are better computed using the idea that
selected values within a group should not impact the counts
for the group values but only the counts for the other
group values.
On the way we have changed two keys in the values returned
by the server:
- 'count' becomes '__count'.
It has been done to avoid a possible clash in case a model would
have a field named 'count' and that the field values would be
wanted for some reason.
- 'name' (multi case) becomes 'display_name'.
It has been done in order to make the select one and multi cases
more similar and factorize some code.
TASK-ID: 2166814
Co-authored-by: Raphaël Collet <rco@openerp.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Alexis Lacroix <laa@odoo.com>
Co-authored-by: Julien Mougenot <jum@odoo.com>
In the search panel, if a select multi was grouped by a field that can
take the value 'false' (like a char field), that value would be confused
with the value false and the group 'false' would never be
displayed (its values would be put in the group false).
This commit avoids that situation by using JSON.stringify instead of
the implicit stringification done when using a value as an object key.
closesodoo/odoo#50647
X-original-commit: 5b19e6c13b636d108e8aa1a09f01124fdb38a577
Signed-off-by: Aaron Bohy (aab) <aab@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>
An attribute 'disable_counters' on fields of the search panel is
supported in case performance issues would be encountered with counters.
The commit dd7022eccd
allowing to use the search panel in other views than the kanban views
has also introduced the search panel arch validation
and the attribute 'disable_counters' was forgotten, so that it was
impossible to use it in practice.
With the present commit, 'disable_counters' is now recognized
as a valide attribute.
closesodoo/odoo#50542
X-original-commit: 4c321d0bcb83286c473a6e6c2b622274fa764393
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, if a many2X field with a big comodel was added
in a search panel, the view using it would crash. For instance that
problem occured in the kanban view for hr.job, where res.users
appears as the comodel for the field user_id.
Now, we fix an arbitrary limit of 200 to the numbers of values to fetch
for each many2X fields in the search panel. This avoid the problem
mentionned above.
Furthermore, in case the limit is attained for a field used
as select="one", the values are displayed without being hierarchized.
Indeed the limit can leads to gaps in the knowledge of the hierarchy
and consequently to a bad representation of it.
Task ID: 2154668
closesodoo/odoo#50334
X-original-commit: 8d57153b34c04952a85f6642951cb2697016da84
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Before this commit, if an action context would contain a key/value pair
like
search_default_foo : 0
the filter foo would be activated, while it should be not considered
as default.
The present commit fixes that situation.
closesodoo/odoo#47958
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
A previous commit makes the graph view render only the finer interval
option for each date/datetime field.
The fact is that in the control panel, different options can be selected
in any order along with other groupbys. This can lead to situations like
'Foo > Date: Day > Bar > Date: Month'
and becomes unreadable.
For that reason we choose to regroup and order options. For the previous
situation, this leads to the following global groupby
'Foo > Date: Month > Date: Day > Bar'.
Our choice also make more sense in a list view for instance.
Task ID: 2198846
closesodoo/odoo#46269
X-original-commit: 59afc869233165e21ef94f485b91d33ac4543b24
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Rendering a graph view with several options selected for a given
date groupby can take too much time and block the page.
Since grouping on the same date/datetime field several times
barely makes sense in a graph view, we choose to use only the finer
option, e.g. 'week' is prefered to 'quarter'.
Task ID: 2198846
X-original-commit: 7e36bee14e18ca17e15de1bacb7ff26010d0b372
Issue
If month - 1 or month - 2 are in the previous year, the filter is
incorrect.
ex: Date = Jan. 2020, Filter = Dec. 2019
=> last_year__last_month = 2018-12 instead 2019-12
Cause
If date is 2020-01-20
Selecting December => adding param "last_month"
Selecting 2019 => adding param "last_year"
Applying "last_month" => date become 2019-12-01
Applying "last_year" => date become 2018-12-01
Solution
Detect the right year to activate by default
when a month is selected and no year is selected.
With that solution it is not possible to get records in Jan. 2020
or in Dec. 2019 only for instance but the global functioning
of date filters stays the same as before.
OPW-2169528
closesodoo/odoo#44208
X-original-commit: 096fdc7d3fe0799aa761c6ad3597569a002c698e
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Co-authored-by: Jason Van Malder <jvm@odoo.com>
The attribute "groups" on filters and fields in a search view arch was not taken
into account anymore.
Now items that should be invisible are not anymore available for selection
in the interface (as expected) but are still activable as search defaults
(and the corresponding facets appear if needed).
Task ID: 2081450
closesodoo/odoo#42125
X-original-commit: ca2514a9fbcd693752367cb566d5c11165b40bd4
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
We don't want the browser to fill inputs in the backend.
Most of the time this is useless but sometimes it is
even problematic. For example, focusing an input in a
modal can trigger autofill not only in the modal but
also in the whole page. If there is an input outside
the modal and it is recognized by the browser as a
candidate to fill, bad things occur.
For that reason, we set the attribute autocomplete to
"none" by default for input elements.
Note that "off" does not work all the time because
the browsers sometimes decide to ignore it.
Task ID: 2076730
closesodoo/odoo#38039
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Before this commit, invisible filters were rendered by
QWeb but hidden in the filter menu. This used to break
the keyboard navigation in the filter menu.
Now we don't render at all those filters since they were
completely useless anyway. This fixes the original
problem.
Task ID: 2057012
closesodoo/odoo#37567
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Before this commit, editing a record e.g. in a form
view and toggling the home menu would cause the discard
warning to be displayed twice when going to the home
menu (in enterprise) and then once again when going to
an other app. This is now fixed.
Task ID: 2043027
closesodoo/odoo#37301
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>
Co-authored-by: aab-odoo <aab@odoo.com>
The gantt view allows the dragged pill to be copied when
the key ctrl (or command) is pressed. In order to be
able to test that feature, we had to modify
testUtils.dragAndDrop. This is done in the present
commit.
closesodoo/odoo#37074
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
With the actual code, some computations are done
in the graph renderer to determine if it is worth
to show the "Stacked" button in the graph view control
panel for the data on hand. It turns out that that
problem is not satisfactorily addressed and is quite
hard from a usability perspective. We prefer to restore
the old behavior as long as we don't have better ideas.
closesodoo/odoo#37188
Signed-off-by: VincentSchippefilt <VincentSchippefilt@users.noreply.github.com>
