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, chat windows could not be sync'ed
between browser tabs for about 10 to 20 seconds.
This issue is caused by the implementation of the
crosstab longpolling, which uses a master-slave
architecture with a single tab being the master tab.
The master tab is responsible for performing the
longpolling RPC, so that it keeps a single HTTP request
for all Odoo tabs. Other tabs are synchronized through
the local storage.
When the master tab was closed, a new master tab election
must occur. However, this process was taking up to 20 seconds,
due to the tab waiting for their next tick on the local
storage to initiate a new election. The tick for a slave
tab is 10 seconds, and it may jumps a tick in case the master
tab is closed exactly before the tick, hence extending the
duration to 20 seconds.
This commit fixes the problem by ensuring that the tab
election for the longpolling is done right after the master
tab is closed. As a result, a new master tab should follow
right away.
Steps to reproduce:
1. open two tabs.
2. open a chat window in one tab: it opens in both tabs.
3. fold/unfold chat window in one tab: both tab should sync.
4. refresh both tabs.
5. fold/unfold chat window in one tab: both tab should not sync.
6. after 10 or 20 seconds, both tabs should again sync.
Task-ID 1911437
closesodoo/odoo#28925
Revision on bus refactoring: https://github.com/odoo/odoo/commit/6448420c5dd160470e465dee7729d19d8d5e7bab
Before this commit, when a user was disconnected for a very long
time, he would receive lots of chat notifications on his next login.
Here is an example of weird behaviour with this issue:
- User folds and unfolds a chat window 50 times
- User disconnects for more than 50 seconds
- User reconnects
==> the chat window rapidly folds and unfolds itself 50 times!
This issue comes from the fact that after 50 seconds without any
longpolling, the web client ignores the last tracked notification
and sents the ID `-1` to the server.
The web client always provides a notification ID to the server
on a `longpolling/poll`. Usually, the server returns all
notifications of the user with an ID greater than the provided ID.
There is an exception with ID `0`, in which all notifications since
the last connection of the user are returned.
The cause of the issue is a mismatch of the special notification
ID between the server and the web client. For the web client, the
ID `-1` is used for not tracking any notification, whereas the
server uses the ID `0` for this case. As a result, when the server
receives the value `-1`, it returns all notifications having an ID
greater than `-1`. In other words, it returns all notifications
related to this user, even the ones received long time ago!
This commit fixes the issue by enforcing the special notification ID
`0` on both the webclient and server.
Note that this logic is similar to 11.0:
- The webclient uses the ID `-1` most of the time to define 'untracked':
https://github.com/odoo/odoo/blob/11.0/addons/bus/static/src/js/bus.js#L154
- However, it passes the ID `0` to the server:
https://github.com/odoo/odoo/blob/11.0/addons/bus/static/src/js/bus.js#L193
The purpose of this change is to make the code clearer and testable.
In this change, the 'tab_manager' static object was merged with the bus
cross tab.
Cleaning was done to clearly define private and public functions as well
as handlers. The methods are documented and the constants are now defined
on the class. The bus use the service behavior with 'trigger_up'.
'bus.CrossTab' who extend 'bus.Longpolling' are instantiated by the
bus service.
The class is always instantiated with a parent, or root in the case of the website
(im_livechat), to use the ajax and localstorage services. So the behavior, perhaps
logger or redefined by the parents.
