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 commit replaces calls to pycompat helpers that were intended for
python 2 <-> python 3 interoperability for python 3 builtins, as python
2 is no longer officially supported by Odoo.
This includes:
* calls to imap/izip/ifilter replaced by map/zip/filter
* uses of text_type replaced by str
* uses of unichr replaced by chr
* calls to implements_to_string, implements_iterator removed
* string_types and integer_types replaced by str, int respectively
* calls to to_native replaced by calls to to_text
This is done in preparation to the removal of these deprecated helpers
in the following commit.
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
That div has been given an absolute position, which does not work inside another
div on the dashboard.
If there are other dashboard elements below, there are unusable since they are
covered by the no_content_create div.
Moreover, there is no create button on the dashboard, so we shouldn't even see
it.
It also spares us from seeing that hideous clippy-inspired smiling paper sheet.
opw 1907650
closesodoo/odoo#29076
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
