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 rev., the following scenario didn't work:
Open manufacturing order and click on Produce button (note that
bom product should have Serial number enabled) then add quantity
in Done field in o2m and press Record Production button in wizard,
it will produce UserError and after then if you change Lot number
field in wizard's o2m then the many2one value doesn't get selected.
This occured because the renderer wasn't updated after the RPC fail
and thus still got an outdated version of the state.
The issue raised after commit: 02eef78bbd which was done to remove
useless rpc call, it's OK to remove rpc call but let's keep
updating renderer.
Related to task ID: #1852715
Co-authored-by: Tejas Shahu <tsh@odoo.com>
Some tests were skipped these last months. This is a slippery slope.
The best time to reactivate them is the moment they were skipped, the
next best time to reactivate them is now. So, this is what this commit
does.
Three kinds of tests were skipped:
- 3 password tests
- 2 kanban progress bar tests
- one keyboard navigation test
Password tests
--------------
When the auth_password_policy addon was introduced, two tests in web/
were skipped, because they would fail when the auth_password_policy
addon is installed.
Since then, a commit was done to change the way the password field works
(commit 5bbbd25edf). With this commit,
the password field is no longer an 'include', but a new field widget.
This means that the skipped tests no longer fails.
Kanban progress bar tests:
--------------------------
In saas 11.2, the 'archive all' feature was removed, but it was readded
in saas 11.4. The tests had to be slightly adapted to make sure they
use the proper css selectors.
Keyboard navigation test:
-------------------------
It is now a functional decision not to allow moving from one cell to the
next by using left/right arrow, so this test is no longer valid.
closesodoo/odoo#28685
Before this commit, when the user is in a form view (edit mode) and
click on a stat button, a new action is added to the action stack. When
the user then comes back to the form view by clicking on the breadcrumb,
it is supposed to be in readonly mode. Before this commit, this was not
the case.
This bug comes from the action manager refactoring, which removed the
view manager. With this commit, we add a new action lifecycle method
which is called when the action is restored.
Note that this commit implicitely changes the semantic of actions with
'target=inline'. As far as I can tell, this only applies to the settings
form view, which can easily be fixed by overriding the restore hook.
closesodoo/odoo#28663
Before this, the action manager only supported auto-triggering actions
from (model, method) or (action_name).
This adds support for providing all the action details via data
attributes:
* model (defaults to current action's)
* resid (defaults to none)
* views (defaults to list, form, unless resid is specified then
defaults to just form)
* domain (defaults to [])
* context (defaults to {active_id, active_ids, active_model} from
current action if the model has not changed, empty otherwise)
The action's name/title is either the link's title (?) or its textual
content.
The swipe between the form view is taking too long to load, and the pager is a
more clean option to switch between form view.
Moreover, the swipe on tabs is not clear anymore.
- Deactivate swipe between form view
- Swipe should only be available on tabs when tabs are too long to fit in one screen.
Was originally introduced by https://github.com/odoo/odoo/commit/f4ee61f950dc1eeb7b3653ca96ea72721512b5e5
Related task: 1924764
closesodoo/odoo#30413
The refactoring also had to be done in order to create a set of unit
tests.
Each behavior can be tested, including the behaviors performed as a
consequence of keyboard interactions (for instance: Enter, Tab...).
This commit also contains some changes to test_utils that were
necessary given the new structure of the wysiwyg editor.
Co-authored-by: Gorash <chm@odoo.com>
- added unaccent search on POS customer/partner and product
- moved unaccent from "mail.utils" to "web.utils"
- added more character to make function accurate
We might use str.normalize(from ES6) but the problem is str.normalize method can not consider some double characters i.e. accented character when normalized it returns 2 normal characters and normalize method returns single character, so here custom unaccent method is used to normalize the string
What we can improve here: We can use str.normalize method and check if string is still have unaccented charaters that we can call our unaccent method but this unaccent method is also working and performing well
closesodoo/odoo#27671
The option `showSearchInput`, which is used on the model field selector to display a search
input that filters the displayed fields, is not set by default.
This includes the model field selector instantiated in the `domain` field widget.
closesodoo/odoo#29986
In some cases, the web client may receive a search view with invisible
filters. This is due to the way field_view_get works. For
example, if there is a group on a filter, then this will be transformed
into an invisible attribute.
In that case, the search view should simply ignore the filter and not
display it. This was broken in the recent control panel refactoring
(note that the search view lacked the possibility of testing that kind
of situation).
closesodoo/odoo#29430
cherry-pick of 13aae100e2closesodoo/odoo#29965
This commit fixes two tests that became meaningless after tweaks
in production code:
- form_tests: use two char fields, as integer fields can't be
unset since rev. c62a4edcb
- pivot_tests: the button is disabled since rev. 4f4f111, but
simulating a click with jQuery bypasses the disabled attribute
This commit also removes unecessary overrides of mockRPC. Those
overrides existed because the attachments part of the sidebar
used to make a search_read RPC, but this has been removed at rev.
1dbb555.
closesodoo/odoo#28650
On a form view (of model A), define a many2one (model B) with a [form|tree]_view_ref context key
In that view, have a x2m field (model C) with a different [form|tree]_view_ref context key
Before this commit, the second load_views (i.e. on the model C) crashed because
the wrong context key was sent to the server, which returned the view to which the _view_ref points
i.e. the view of the model B
After this commit, we clean the context of subviews loading, because those keys are only useful for the python
and one shot. Hence, there is no crash
OPW 1903780
closesodoo/odoo#28260
When the qunit tests runs they are expecting the new line to be the character 10,
but in windows the new line is 10+13.
The test has been updated to ignore the character 13.
closesodoo/odoo#28599
This commit fixes two tests that became meaningless after tweaks
in production code:
- form_tests: use two char fields, as integer fields can't be
unset since rev. c62a4edcb
- pivot_tests: the button is disabled since rev. 4f4f111, but
simulating a click with jQuery bypasses the disabled attribute
This commit also removes unecessary overrides of mockRPC. Those
overrides existed because the attachments part of the sidebar
used to make a search_read RPC, but this has been removed at rev.
1dbb555.
closesodoo/odoo#28651
The file relation_fields_tests.js was a huge 12K lines files for which some editors have a
hard time managing.
We have split it in 4 files to be more managable and removed remove unused data
and import.
closesodoo/odoo#28561
Suppose you are editing a SO to add a new line. Depending on the configuration,
a sale order line wizard may open (e.g. if packages are activated).
This wizard is a form view, opened from the tree view of the sale order lines.
We have commit 8e5156938a
that adds extra fields from the originating view.
(However it doesn't work if the other view is inlined, so we modify this part to
add the extra field even in this case.)
Then we need the field info from the origin view in the target view;
we do so by extending the former with the content of the latter.
opw 1904337
closesodoo/odoo#28441
Have a form record with a progress bar
Modify the max_value of the progress, as well as the current_value bar through an onchange
Before this commit, the new max_value was not taken into account
After this commit, it is.
closesodoo/odoo#29056
When creating a SO line and clicking on search more for product_id
Before this commit, every user had the button "Create" to create a product.product
After this commit, only user in groups that actually can create a product have the button
OPW 1910371
closesodoo/odoo#28924
Define a x2m tree view with a default_sort including more than 1 field to order the list against
Before this commit, the second field was never used
After this commit, it is used
OPW 1909785
closesodoo/odoo#28840
With the BS4 update, a traceback occured when clicking on a m2m tag using colors
in a list view.
When using colors on m2m tags, the badge was wrapped inside a `dropdown-toggle`.
However, there is no `dropdown-menu` by default (it is only rendered in FormFieldMany2ManyTags
when clicking on the `.dropdown-toggle`, hence the traceback.
The `dropdown-toggle` class is now only set if necessary.
Task 1925313
closesodoo/odoo#31445
Have an editable list that begins with a date/time field
create a line.
The first field is focused and the datetimepicker is popped up
Now, stroke ESC key
Before this commit, there was a traceback because the datetimepicker received an erroneous
BLUR/INPUT event
After this commit, there is no traceback as we detroy the widgets of the line
(including the datetimepicker) before removing the row from the DOM
OPW 1932409
closesodoo/odoo#31342
This rev. fixes 3 issues with async (field) widgets in the kanban
view.
From rev. 5faec34a, widget'$el doesn't exist before start. This
means that for async widgets, one can't interact with the widget's
$el right after calling appentTo. In KanbanRecord, this is exactly
what we did for both field widgets (<field name=.../>) and widgets
(<widget name=.../>).
Moreover, when the kanban view was updated (e.g. when the user
refined the search using the search view), and the rendering was
async (because of the presence of an async widget), the renderer
didn't wait at all for the widget to be ready before updating the
view. This caused flickering, mostly, but also a crash in
accounting with the JournalDashboardGraph widget (because
on_attach_callabck was called before the widget was ready). To
reproduce this particular issue, go to accounting, add a filter
that doesn't match any record and save it as favorite (default),
press F5 (no record is displayed), remove the filter.
opw-1925079
opw-1925479
Fixes#30087Closes#31254closesodoo/odoo#31327
In some cases, and for historical reasons, the groupby property can be
expressed as a string (for example, 'stage_id') instead of a list of
strings (for example, ['stage_id']).
However, the support was not complete. A crash could happen in some
cases. For example, if there is a group_by: 'stage_id' property in the
context of an action, it works in list view, but adding that view to the
dashboard would result in a crash, without this commit.
Let's assume a form view with field A and B (a one2many list), with
a column with attrs column_invisible depending on A.
If the user sets A manually, everything works fine (the column is
hidden/shown directly). However, if A is updated by an onchange
(e.g. depending on the number of rows in B), it doesn't. This
rev. fixes that issue.
Related to Issue: 1851451
Co-authored-by: Priyanka Kaakdiya <pka@odoo.com>
When a view is loaded, it checks which fields it has to load.
In the case of a many2one, it could be the case that a context key is present in
one view and not in the other; if it happens, we should reload the data, as a
name_get result could vary.
opw 1891295
closesodoo/odoo#28298
Before this commit, when loading the data and calling the prostprocess,
the viewType was not correctly passed which could lead to broken
behaviour. For example, if one was to load a record from a list view
embedded in a form view, the viewtype passed was the list which
prevented to load the data from the form view.
OPW 1891295
closesodoo/odoo#28279
When creating a record in a grouped kanban view, it tries to add
the record to the first column but if no column exist, it fails
to find the first one and raise an exception.
This PR correct that bevahior by checking it exists a column and
fallback to the view form when it does not.
opw-1902851
closesodoo/odoo#28262
Add an 'enableRelationalFetch' option in _readGroup who force to make
only one rpc for x2m and reference fields.
Usefull to avoid useless (and blocking when too numerous) rpcs (tags
field in a kanban view for example).
Task #1878113 (2/2)
closesodoo/odoo#27731
Rev. 42e1efded5 aimed to disable the quick create feature when
grouped by date(time) fields, by only enabling it for char, boolean
and many2one fields. However, the selection case is quite important
and must be handled as well. This is what this rev. does.
Task 1878254
When a kanban view is grouped by a char or a boolean field, and the
quick create option is enabled, the correct default value for the
grouped field (i.e. the value of the column in which the record is
created) should be given (either in the context if that field isn't
in the quick create form view, or as a default value in that form
view otherwise).
Before this rev., it wasn't the case, as it was only working when
grouped by a many2one field.
Task 1878254
when grouped on field types for which it isn't supported.
Rev. 42e1efd disabled the quick create feature when the view is
grouped by date(time) fields. However, it hasn't been correctly
forwardported to 11.0 (with the new views). Indeed, the check was
done only once, at the initilization of the view. So if the user
selected another field to group by afterwards, the quick create
feature wasn't enabled/disabled accordingly.
Moreover, we didn't check if it was available when the user clicked
on CREATE in the control panel. So even if it wasn't (and thus if
there were no '+' icon in the columns), when the user clicked on
CREATE, the quick create widget was inserted in the first column.
This rev. fixes both issues.
Task 1878254
closesodoo/odoo#27867
Géry Debongnie