| Age | Commit message (Collapse) | Author |
|---|
|
A fix attempt for the clickEveryWhere test was made in 39e71353c5.
Unfortunately, the last modification of the fix were not tested on the
runbot and introduced two new issues.
1) The click method on the home menu has been changed to use an enhanced
_click function. This function crash when the jquery element is empty.
As this menu does not exists in community, the test miserably fails.
2) A "focus" event was added in the _click function that simulates a real click.
But the "focus" event is not a mouse event and as nothing to do there.
With this commit, the _click function returns immediatly when the
element is empty.
Also, the "focus" event is removed from the _click
simulation but a focus method is used to give focus to the close button.
Giving the focus to the cancel button is itself a fix for the
DateTimePicker field (see 39e7135).
closes odoo/odoo#32082
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
|
|
During the clickEverywhere test, when a modal is opened, the hide method
is called to bypass it. This is not realistic and does not work in some
cases.
For example in Point of sale, menu "Reporting/Sales Details", a modal is
opened with a DateTimePicker (tempus dominus) already opened.
When hiding or closing the modal, the DateTimePicker needs to perform
some cleanup. If the modal is simply hidden, the DateTimePicker is not
cleanly destroyed.
With this commit, a modal is closed by clicking on its close button and
before that, the focus is set on the close button to let the
datepicker widget do its stuff on losing focus.
Also, a more realistic click is done by trigerring more events (code
adapted from tour helper).
closes odoo/odoo#32038
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
|
|
Since odoo/enterprise@b830ea7ed2a, the enterprise home menu is asynchrnonous.
Because of that, the clientActionCount variable is updated too late and
this counter is screwed up, making the test fail.
With this commit a setTimeout 0 is used to click on home menu in the
next tick and then update the current action count.
Also
* the test is adapted to stop immediately when an error is catched.
* the initial click on home menu is moved into debug manager because
the python test launcher uses the correct location already.
Thanks to @VincentSchippefilt and @aab-odoo
closes odoo/odoo#31949
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>
|
|
Part of task 1896658
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Christophe Matthieu <chm@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: David Monjoie <dmo@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
Co-authored-by: svs-odoo <svs@odoo.com>
Co-authored-by: Vincent Schippefilt <vsc@odoo.com>
|
|
When evaluating js tests using the browser_js method, they are
considered a success when 'ok' is found in the console log and a failure
if 'error' is found instead.
This is not very robust and recently failed with this commit : 7410de111fe
It adds a filter named 'Error' in a view, when the 'click_all' test
clicks on this filter, a message with the name of the filter is written
in the console, wrongly leading to a test failure.
With this commit, the browser_js method expects a log message in the
browser console with the explicit text "test successful".
On the other hand, any error in the console log will lead to a test
failure but a test can be forced to fail with the explicit error message
in the browser console "test failed".
As a bonus, the python logger should now also log browser js trace messages.
closes odoo/odoo#31158
|
|
closes odoo/odoo#30045
|
|
The information of the active model and record was not given in the context
Records created from the Manage Messages and Manage Attachements in the debug
menu were not linked to the current records
Add context in test too
closes odoo/odoo#27766
|
|
Since 4cd379cf6e the ControlPanel is now a child of the viewController.
This breaks the clickEveryWhere test.
With this commit, the view_controller selector is adapted in the clickEverywhere
test.
closes odoo/odoo#29383
|
|
This branch introduces a large-scale reorganization of the
component tree generated by the web client. The short version is
that now, the control panel is a child of the view controller and
no longer a sibling. Graphically (and simplified), we go from
this:
webClient
/ | \
... ... actionManager
/ \
controlPanel viewController
/ \
to this:
webClient
/ | \
... ... actionManager
|
viewController
/ | \
ControlPanelController
/ \
CPRenderer CPModel
The motivation is that this work moves the code where it should be.
Before this commit, it was kind of weird to have code in the
controllers to render buttons outside of their root node (in
renderButtons). Also, the action manager had to take care of
coordinating search view states between view transitions.
So, this work simplifies the code. It also makes it easier to
extend. We see day after day that Odoo needs to take care of more
complex UI needs, and in many cases, these needs were quite
difficult to implement (we prefer spaghettis in our plates, not in
our code). The changes in this branch should open the way to
implement these features.
For example,
- it will now be easy to add the possibility of views (for example,
the search view or a new ControlPanel view) to add custom buttons
(of type action or object) in the control panel.
- Another need will be to serialize/ restore the state of the
search view across action boundaries (needed by the dashboard).
- Another example is the possibility for views to customize easily
the presence/absence of sub menus (filters/groupbys/favorites/
time range/...)
- Another need is an easier way for views/client action to customize
their control panel.
This commit also contains a large rewrite of the search view (so it
is more inline with our architecture and easier to maintain).
Part of task 1893568
Co-authored-by: Aaron Bohy <aab@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Martin Geubelle <mge@odoo.com>
|
|
Rev. 7c3d5dc0 recently added new helpers to use in the tests, and
moved some existing helpers to testUtils sub groups (like .dom or
.mock).
This rev. adds a compatibility layer to ease forwardports.
closes odoo/odoo#28824
|
|
During the refactoring of the js test suite, in abf32b8b, the
click_everywhere test was inadvertently updated to use the helpers.
Some missing semi-colons were fixed too.
closes odoo/odoo#28820
|
|
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.
|
|
|
|
Also clarify a variable name referencing a node instead of a jquery
object.
|
|
The navbar in community now looks more like the navbar in enterprise.
Here is a sum-up of the changes in community:
- The navbar in community is now in blue, instead of black.
- No more app list that almost fills the whole navbar: there is
now an "Apps Menu" in the left-most side of the navbar.
- No more sidebar for the menus inside an app: those menus are
now located in the middle part of the navbar.
The navbar in community does not support mobile (< 768px width),
but it should still somewhat usable on most mobile devices.
As for the website navbar, it has been unchanged and should still
support mobile layout.
Task-ID 1878649
|
|
- added two new actions to the form view debug action list,
both opens list (+ form) views of messages and attachments respectively
for which the domain is restricted to the current record.
task: 1860031
|
|
|
|
This commit adds a new js test in web that enters each app and click on
each view switcher, each menu and each search filter.
This test is tagged '-standard' and 'click_all' as it could last a long
time, that way it's not executed by default.
It could also be started from the browser console with
'clickEverywhere();'.
|
