to ControlPanel/Search view refactoring.
The ControlPanel being now inside the DOM of client actions, those
existing widgets needed to be adapted (in the way they define if
and how they want a ControlPanel, and in the way the manipulate
their DOM as it slightly changed). Tests needed to be adapted as
well.
Part of task 1893568
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
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 this commit, it was not possible to access
apps from 'Browse apps' in the Settings menu when
at least one app was installed.
This is caused by the clickable DOM element being a `<a>`
with `href='#'`. This redirects to the 1st app, usually
the 'Discuss' app, which prevents opening the kanban view
with apps.
This commit fixes the issue by preventing the browser to
change the URL in the address bar when clicking on
'Browse apps' from the 'Settings' application.
Closes#27434Closes#27442
Before this commit, it was not possible to set up a company.
This is caused by the clickable DOM element being a `<a>` with
`href='#'`. This redirects to the 1st app in community (usually
the 'Discuss' app), which prevents opening the form view to
set up information about your company.
This commit fixes the issue by preventing the browser to change
the URL in the address bar when clicking on 'Set up'.
Closes#27434Closes#27442
Before this commit, there was an issue when trying to load
a translation from the 'Settings' application.
- Go to 'Settings'
- Click on 'Load a translation'
> It redirects to 1st app (community) or home menu (enterprise)
This is not a big issue in enterprise, because the modal is
that let the user load a translation is still prompted.
This is however not the case in the community version.
This issue is caused by 'Load a translation' being a `<a>` with
`href='#'`. The purpose of the `href='#'` is to have the pointer
cursor on mouse hover. However, when clicking a `<a>` with `href`,
the browser changes the URL in the address bar with the content of
the `href`, which for the value `'#'` is linked to the top of the
main page. In community, this redirects to the 1st installed app
(usually 'Apps' or 'Discuss'), whereas in enterprise it redirects
to the home menu.
This commit fixes this issue by preventing the default browser
behaviour when clicking on "Load a translation", so that it does
not change the URL in the address bar.
Closes#27434Closes#27442
Before this commit, the planner section of the settings weren't translated.
This was because the context was not sent along with the search_read that fetches planners data
After this commit, the planner section is correctly translated
OPW 1881092
closes#26766
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