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
This commit removes all the 'extend' initially introduced to avoid code
repetition and ensure visual consistency across Bootstrap and Owl dropdowns.
Despite achieving the desired results, using 'extend' in this context
was seriously impacting the bundle generation time, probably due to an
underestimated amount of Apps' legacy-code applied on these elements.
In order to achieve the same results, the chosen strategy is to add
Bootstrap default classes directly into Owl dropdowns.
Also, it moves code related to bootstrap dropdown in 'webclient.scss',
leaving 'core/dropdown/dropdown.scss' for Owl code only.
Due to the discrepancies between Bootstrap and Owl html
structure, the '.dropdown-item' class could not have been added
directly to Owl's '.o_dropdown_item' itself, without refactoring
the Dropdown component structure.
// ==== Bootstrap 4.6 default Structure ================================
<div class="dropdown-menu">
<button class="dropdown-item" type="button">Action</button>
<a class="dropdown-item" href="#">Another action</a>
</div>
// ==== OWL default Structure before this commit =======================
<ul class="o_dropdown_menu">
<li class="o_dropdown_item">
<span>Action</span>
</li>
<li class="o_dropdown_item">
<a href="#">Another action</a>
</li>
</ul>
// ==== OWL Structure after this commit ================================
<div class="o-dropdown--menu dropdown-menu">
<span class="dropdown-item">Action</span>
<a class="dropdown-item" href="#">Another action</a>
</div>
// ==== web.assets_backend.css Bundle Generation Comparison ============
With all modules installed (enterprise edition over runbot):
Before this commit, bundle took ~2.5s and ~4s to generate and weighted ~322kB (~2.5MB uncompressed)
After this commit, it takes between ~1.2s and ~1.6s and weights ~257kB (~1.6MB uncompressed)
closesodoo/odoo#77649
X-original-commit: 84715436d87bb05b421bc9ccaacda67d07571690
Related: odoo/enterprise#21370
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
Co-authored-by: Stefano Rigano <sri@odoo.com>
Co-authored-by: François Georis <fge@odoo.com>
Co-authored-by: Bruno Boi <boi@odoo.com>
This commit handles the adaptation of any component using the search
model's 'action' and/or 'view' key, now replaced by the environment
keys 'actionContext' and 'viewContext'.
Affected modules are:
- base_import
- board
- crm
- google_spreadsheet
- project
X-original-commit: 40f1ae87e1436192a70a8a7432eb72d379cfa6dc
Part-of: odoo/odoo#77463
The pivot and graph views have been rewrote in owl in [1]. However,
the former implemention has been kept as it is still used in some
cases (e.g. board application, studio, PieChart widget), but they
are lazy loaded [2].
Before this commit, both the new and former implementations mostly
shared the same DOM (in particular, their root element had the
same classnames). It means that the scss rules of an implementation
might interfer with the other, and vice versa.
This commit adds the "legacy" keyword in the root classnames of
those views, and properly namespaces the scss rules of legacy views
to properly dissociate the style of new and legacy views.
For the pivot view, we re-used the same scss file, so in this
commit, we duplicate it (one for the new view, the other, lazy
loaded, for the legacy view).
[1] 0134495ba5
[2] bd3cf85c841168dfd87f7166b545dd00d9b38bf4
closesodoo/odoo#77323
X-original-commit: 3862d5aae1df72d3585f915e8a2a2626322e74ad
Related: odoo/enterprise#21223
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
This commit replaces the control panel dropdowns with the new <Dropdown/> component, in order to get consistent through the new/legacy views (because the current Odoo version is in a state where some views uses the new infrastructure and some others are still not converted - see odoo/odoo#73311).
The diff seems massive, but it is mostly due to tests adaptations.
closesodoo/odoo#77001
X-original-commit: d679cd0d8ba9a2420e81a42a698763e9be2327e1
Related: odoo/enterprise#21077
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
A number of functions from `web.test_utils` have been deprecated at
the module root and should be called through submodules.
Fix a bunch of remaining cases. Also add a few missing `await`s on
`triggerMouseEvent` calls. Don't bother rewriting the imports in
unpacking style as for most updating the imports is unnecessary. Do so
for `field_one2many_tests.js` where we have to rewrite the imports
anyway:
* recursively import controlPanel, createView, mock.patch and
mock.unpatch
* remove the aliasing of controlPanel to cpHelpers
This commit splits the 'getActionManagerTestConfig' helper into 2:
'setupWebClientServiceRegistry' and 'getActionManagerServerData'.
The first one is now automatically called by the 'createWebClient'
helper, as it properly setups the service registry with all services
required by the WebClient component.
The second one generates a few data (menus, actions, views...) that
can be used in tests. That helper is mainly useful for action tests
(formerly ActionManager tests) in web. With this refactoring, they
are no longer generated for each test in the whole codebase that
spawns a webclient, as before this commit.
closesodoo-dev/odoo#906
Related: odoo-dev/enterprise#161
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
When opening the dashboard in form view, some of the view options should
always have a certain value (in particular, the target should be inline,
and the form view should not have action menus or a control panel).
Previously, this was done through an override on the action manager when
executing a window action. In wowl, the action manager has been replaced
with an action service and its methods cannot be overriden.
This commit solves the same problem with a different approach, by
overwriting these options before trying to extract the view params from
the action.
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>
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>
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>
*:board,hr_skills
Hold on tight, this is a tricky one.
Allows *any* readonly list view (only plain lists, not x2manies) to
become partially editable when checking records.
This means that once checked, a record line acts just like it was
in an editable list. You can click on it, edit any of its values as long as
they're not constrained by readonly modifiers, and save them on the fly.
Clicking on an unchecked record will have the same effect as before:
it will open the record, regardless of the other selected records.
You can also check multiple records and edit them all at once by
changing the value of one selected record (just like standard multi edition).
Keyboard navigation is also allowed between selected records (TAB and SHIFT+TAB
to navigate and ENTER to save).
/!\ If a list is only made of records having all of their fields locked by
readonly modifiers, checking a record and clicking on it will do absolutely
nothing. This is to keep consistency with the rest of the specs.
Task 1967602
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>
Following f4fbaf1efa
which changes the label/checkbox structure into:
```
<div class="custom-control custom-checkbox">
<input type="checkbox" class="custom-control-input" id="customCheck1">
<label class="custom-control-label" for="customCheck1">...</label>
</div>
```
So, before this commit, there may have been multiple input with the same Id.
The consequence is that, when clicking on a label, the browser would take the first Id it found
which was erroneous, because all checkboxes in Favorites menu had the same Id
In reality, the use case goes as:
- open a x2m,
- search more
- Favorites > Save current search
> click on one the two checkboxes
> The dropdown closed, without checking the box
After this commit, when clicking on the checkbox in the favorites menu
the checkbox is toggled and the dropdown stays. Also, the checkboxed have now unique ids
OPW 1974587
closesodoo/odoo#33032
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
The `read` done by `_fetchRecord` in `basic_model.js` expicitly set a
`bin_size: true` in the context. That context option tells the backend
to send the size of the binary payload instead of the payload itself
thus slim the response size. Frontend widgets are then responsible to
fetch the actual payload in a separated http req.
The `search_read` done by `_searchReadUngroupedList` didn't set the
context option thus all the binary fields were sent b64 encoded along
with the `search_read` response.
opw-1963842
closesodoo/odoo#33014
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
the group by key in action context can be a single string
containing the name of a single field or a list of string
reprenting a list of field names
Before this commit, the board did not take this into account
After this commit, it does and supports both expressions
OPW 1956130
closesodoo/odoo#32471
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Several cases:
- on a dashboard viewtype, put a group by on the chart
- on a list viewtype, apply a group by and an ordered by
In both cases the parameters were not taken into account when
rendering the view in the board app
ref: 40dd121938
This was because, when saving an action for the board app
we tried to fill the "action's context" with only the contexts of:
- the search query (where context is just one of attributes)
- the ownQueryParams of the controller
Doing that, some other vital attributes, like group_by and orderedBy
where forgotten in the process. "C'est ballot!".
Also, the "real context" of those attributes was saved
as a context within the context.
But (!), the action's context will behave as a "real context" when spawning
views and controllers down the line.
After this commit, we flatten as much as possible all those nested
contexts at the time of saving the view
OPW 1944857
The board created out of a tree view wasn't taking the default domain of
the view.
opw-1958349
closesodoo/odoo#32240
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
With this rev., when there are a lot of groups in a grouped list
view, groups are displayed under several pages, whereas they were
all displayed in the same page before.
This is especially interesting with the new 'expand' attribute, to
ensure that we don't read records for a large number of groups.
By default, the groups limit is set to 80 (like records), and to 10
is the 'expand' attribute is set to true. This limit can be
overriden with the 'groups_limit' attribute.
Part of task 1915702
Before this rev., it crashed when the user clicked on a pivot cell
in the dashboard, whereas it should have performed a do_action to
open the records in a list view.
This was due to a leftover event handler (with the handler function
being actually removed) in commit 38dc5c18b.
Issue reported on the saas-12.1 migration pad.
closesodoo/odoo#31367
This rev. adapts the code of the 'Add to Dashboard' entry of the
Favotires menu, according to the large SearchView refactoring. It
also does some tweaks for the dashboard app due to the move of the
ControlPanel from the ActionManager to the controllers.
Part of task 1893568
This rev. introduces robust helpers to use in the JS tests suite to
interact with DOM and components, and starts using them (almost)
everywhere.
All the helpers are exposed though testUtils.js.
There are 2 kinds of helpers:
1. Assertions
-------------
* assert.containsNone, containsN, containsOnce check that the DOM
(or a specific part of the DOM) contains a `selector`. It
generates a correct error message automatically.
ex: assert.strictEqual(form.$('.o_form_editable'), 1, "msg");
-> assert.containsOnce(form, '.o_form_editable');
* assert.isVisible, isNotVisible check that the DOM has an element
visible or not. They also check that the element is actually in
the DOM (before most tests didn't verify this).
* assert.hasClass, doesNotHaveClass, hasAttrVAlue, check specific
properties of a DOM element, and also validate that it is
applied on a single existing DOM element (before most tests
didn't verify this).
ex: assert.notOk(form.$('button').hasClass('btn-primary'));
-> assert.doesNotHaveClass(form.$('button'), 'btn-primary');
2. Utilities
------------
The goal of the utilities is to centralize the definition of many
standard components and interactions, ensuring that when we
refactor the JS framework, we do not need to change all the tests.
Existing mock utilities (addMockEnvironment, intercept, path,
patchDate, unpatch and fieldsViewGet) are moved to
'testUtils.mock.*'.
Existing DOM utilities are moved to 'testUtils.dom.*'.
New dom utilities are created for opendDatePicker, click,
clickFirst and clickLast. Helper `click` verifies that there is
exactly 1 element visible in the DOM you click on, `clickFirst`
and `clickLast` verify that there are more than one element on the
DOM.
ex: form.$('button').click();
-> testUtils.dom.click(form.$('button'));
New Form utilities: (testUtils.form.*)
clickEdit, clickSave, clickCreate, clickDiscard, all clicks on
the control panel buttons of the form.
`reload` reloads the form data.
New modal, graph, kanban and pivot utils (testUtils.pivot.*,
testUtils.kanban.*, etc.).
New fields utils: (testUtils.fields.*)
* editInput, editSelect: allow to change the value of a field,
using a selector to identify it. They validate that the input
exists and trigger the change event automatically.
* editAndTrigger: allow to modify a field and trigger specific
events after the value change
* many2one (testUtils.fields.many2one.*)
clickOpenDropdown, clickHighlightedItem, clickItem,
searchAndClickItem: use a field name instead of a selector and
do all the complex mechanism to open, filter and highlight
many2one fields.
Joint work with aab, dam, ged, mge, svs and vsc.
Before commit 60f143c8e7, the dashboard
parameters did not use the parameters from the action, so some important
information could be lost.
However, in this same commit, the action context overrides the context
from the user defined views, which means that some information is lost.
For example, customized group bys are ignored.
This commit fixes the issue with some careful context manipulation.
Some special care was done to remove the groupby from the action context
if it is not empty, because that same logic is used in views.
forward port of 62cbc5f
Have a user in English, put a sale report as "favorite" (pinned to dashboard app)
Change the user's language
Before this commit, the pinned view was in English (because it was recorded that way)
After this commit, the pinned view is in the user's language.
OPW 1890664
closes#27799
Have a user in English, put a sale report as "favorite" (pinned to dashboard app)
Change the user's language
Before this commit, the pinned view was in English (because it was recorded that way)
After this commit, the pinned view is in the user's language.
OPW 1890664
closesodoo/odoo#27574
Add a search containing a domain to dashboard. Remove that domain.
Do a new search with a different domain.
Add that search to dashboard;
the domain sent would be the concatenation of the two domains.
We make it so that only the last domain is sent, with a test.
opw 1907650
closesodoo/odoo#28843
The view_mode attribute is automatically set to the 'action' nodes
when the action is added to the dashboard using the 'Add to
dashboard' button in the searchview. However, other dashboard views
can be written by hand (see openacademy tutorial), and in this
case, we don't want to hardcode action's params (like context or
domain), as the dashboard can directly retrieve them from the
action. Same applies for the view_type, as the first view of the
action can be used, by default.
Before this rev., the second usecase wasn't handled, and it crashed
when no view_mode was specified. This rev. also ensure that the
context and domain are correctly retrieved from the action.
Closes#24088closesodoo/odoo#27519
The view_mode attribute is automatically set to the 'action' nodes
when the action is added to the dashboard using the 'Add to
dashboard' button in the searchview. However, other dashboard views
can be written by hand (see openacademy tutorial), and in this
case, we don't want to hardcode action's params (like context or
domain), as the dashboard can directly retrieve them from the
action. Same applies for the view_type, as the first view of the
action can be used, by default.
Before this rev., the second usecase wasn't handled, and it crashed
when no view_mode was specified. This rev. also ensure that the
context and domain are correctly retrieved from the action.
Closes#24088closesodoo/odoo#27517
It is possible in a dashboard item to open a form view of a record.
The view did not take into account the action used to display the item,
so for example: from a customer invoice clicking on a record would
display the "Vendor Bill" instead of "Customer Invoice" view.
With this fix, when a view is being loaded to be displayed in the
dashboard, we save a reference to a possible form view and if the form
view is displayed, we use this reference.
opw-1865454
closes#25718
Rev. 69c9500e recently added option 'keepSearchView' to doAction in
the ActionManager. When set to true, the searchview of the current
action is re-used by the executed action.
This caused issues with the dashboard, as the wrong action id was
used to save the current action to the dashboard (it was the one
of the action for which the searchview was instantiated, not the
one of the current action, executed with option keepSearchView set
to true). For instance, go to Website (in enterprise), in the
new dashboard (view) expand the graph view, try to add the graph
action to the dashboard (board).
Task 1835670.
Mathieu Duckerts-Antoine