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
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
Regenerate all child translations based on the .pot
Remove the terms that are either equal to the parent, either equal to the
source term.
Remove empty translation files
Christophe Simonis