The test may fail non-deterministically from intercepting an
heartbeat in the local storage. Only a document thread window fold
state change from the local storage should be intercepted.
Closes#43072
Before this commit, there could be an infinite loop when changing
the chat window state of a document chat window.
This is caused when mutiple tabs overwrite the chat window state
with a different value everytime, resulting to an infinite loop.
Accross multiple tabs, `setItem` and `onStorage` are not synchronous.
That's why tabs should communicate through local storage events
instead of actual value in the local storage.
To illustrate the issue, suppose there are 2 tabs (T1 and T2) with
one document chat windows (C) and the following user interactions:
- T1 and T2 both have C open
- on T1, user folds C
- on T2, user folds C
Now let's add an example of local storage (LS) logics that could
apply from above example:
- T1 and T2 both have C open
- on T1, user folds C
[1] T1 writes 'C folded' in LS
- on T2, user folds C
[2] T2 writes 'C folded' in LS
[3] T2 detects 'C folded' in LS (from [1])
=> T2 writes 'C folded' in LS
[4] T1 detects 'C folded' in LS (from [2])
=> T1 writes 'C folded' in LS
[5] T1 detects 'C folded' in LS (from [3])
=> T1 writes 'C folded' in LS
[6] T2 detects 'C folded' in LS (from [4])
=> T2 writes 'C folded' in LS
etc...
This scenario could have been easily prevented by not writing on
local storage when the chat window state has not changed. However,
this wouldn't fix this scenario that also introduces an infinite
loop:
- T1 and T2 both have C open
- on T1, user folds C
[1] T1 writes 'C folded' in LS
- on T2, user folds C
[2] T2 writes 'C folded' in LS
- on T2, user unfolds C
[3] T2 writes 'C unfolded' in LS
[4] T2 detects 'C folded' in LS (from [1])
=> T2 writes 'C folded' in LS
[5] T1 detects 'C unfolded' in LS (from [3])
=> T1 writes 'C unfolded' in LS
[6] T2 detects 'C unfolded' in LS (from [5])
=> T2 writes 'C unfolded' in LS
[7] T1 detects 'C folded' in LS (from [4])
=> T1 writes 'C folded' in LS
[8] T2 detects 'C folded' in LS (from [7])
=> T2 writes 'C folded' in LS
[9] T1 detects 'C unfolded' in LS (from [6])
=> T1 writes 'C folded' in LS
etc...
This commit fixes the infinite loop issue:
- by turning local storage read during cross-tab communication into
local storage event read instead. This should prevent race
conditions based on read/write operations in local, since their
order is not guaranteed accros tabs.
- by isolating document chat window state to their own local
storage entry. This should prevent a tab from notifying a chat
window state that it didn't change, which may also result in
an infinite loop.
Some tests were adapted from the changes above. Also, some tests did
pass thanks to local storage being mocked by a ram storage: the
handler `_onStorage` should have been called, but it didn't because
it was registered on the actual local storage instead of the ram
storage. In order to make tests pass again, the following additional
changes were required:
- Cross-tab bus service now exports the unique tab ID with
`getTabId`.
- document thread entries in local storage now track the tab ID, so
that self-tab ignore their own local storage writes.
Task-Id 2034997
Closes#36177
Before this commit, most new messages added to the mail manager were
handled as if recently posted from a document thread. As a result, it
was frequently setting a new item in the local storage to notify
other tabs from these new messages.
The intent of this behaviour is to notify other tabs of newly posted
messages in a document thread, without using a longpolling
notification. That means this logic should only apply on messages
that have been recently posted on a document thread.
Sometimes, this issue was breaking the local storage on Firefox.
It showed the error message "Quota Exceeded Error" whenever `setItem`
was used, even when items were removed beforehand. The capacity of
the storage was only a few Kbs on this domain, far from reaching the
maximum capacity. We think that this error comes from the concurrent
`setItem` on multiple tabs, but this is very hard to reproduce.
This commit fixes the issue by limiting the `setItem` to the tab
that really posted the message. Tests have been adapted in order to
pass only with this fix.
Before this commit, most new messages added to the mail manager were
handled as if recently posted from a document thread. As a result, it
was frequently setting a new item in the local storage to notify
other tabs from these new messages.
The intent of this behaviour is to notify other tabs of newly posted
messages in a document thread, without using a longpolling
notification. That means this logic should only apply on messages
that have been recently posted on a document thread.
Sometimes, this issue was breaking the local storage on Firefox.
It showed the error message "Quota Exceeded Error" whenever `setItem`
was used, even when items were removed beforehand. The capacity of
the storage was only a few Kbs on this domain, far from reaching the
maximum capacity. We think that this error comes from the concurrent
`setItem` on multiple tabs, but this is very hard to reproduce.
This commit fixes the issue by limiting the `setItem` to the tab
that really posted the message. Tests have been adapted in order to
pass only with this fix.
note: backport of 12.2 4bde721f9
opw-2031960
closes#35588
Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>
Before this commit, a user could unintentionally discard a
notification from a document that he does not have access
rights at the moment.
Steps to reproduce:
1. Setup:
- Odoo with multi-company
- Two companies: "MyCompany" and "SuperCompany"
- Two users "Admin" and "Demo", both have access to being in
both companies
- "Demo" has Notification management in Odoo in the user preferences.
- "Admin" is logged in "MyCompany"
- "Demo" is logged in "SuperCompany"
2. Scenario:
- "Admin" mentions "Demo" in a log of a document from "MyCompany"
- "Demo" receives the notification and click on the notification
from messaging menu.
> Dialog prompts that Demo does not have access to the document (OK)
> Empty chat window is open (not OK)
- "Demo" closes the chat window
> Notification is marked as read (not OK)
This commit fixes the issue by aborting the opening of a
chat window if the user does not have the access rights
at the moment. It should prevent marking the notification
as read by mistake by closing the chat window.
Task-ID 1931313
closesodoo/odoo#30414
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.
This commit makes small improvements on the messaging menu with
the new module `mail_bot`:
[IMP] When OdooBot has a request, it now adds "+1" to the counter of
the messaging menu. The related preview also has a bold title,
and displays "(1)" next to the title.
[REF] Static previews are no longer in mail_service. This was only
used for "OdooBot has a request" preview. This logic has now
been moved to the module `mail_bot` (was previously in `mail`).
[FIX] Title of response of push notifications permission clearly
states whether permission has been granted or denied
(was displaying "[Object object]" before this commit).
Task-ID 1877502
This commit fixes some bugs on thread windows, and make some
improvements on tests related to thread windows.
Fixes:
1. Correctly position last visible thread window when there are more
open thread windows than available slots.
2. Closing a thread window now marks it as read.
3. Can now fold/unfold the blank thread window (aka 'New' thread window).
Tests cleaning:
1. Removed unnecessary 'before assertions' in thread window tests.
> Solved with this: https://github.com/odoo/odoo/commit/9b1daa1218f7adf9d741afba607ef5b55b16e3e6
1. Added basic rendering test for a (non-blank) thread window.
2. Cleaned thread window tests
> Split in different files.
> Grouped in 'Thread Window' QUnit module.
This commit makes a lot of small improvements of the JS of mail and
related modules.
A. Mail Manager
---------------
im_support:
- [REF] Slightly more robust way to determine a support
message, so that it more reliably falls back on
default kind of message (i.e. support channel UUID
should be clearly set).
mail:
- [REF] Improved method names for readability purposes.
Some examples:
- `fetchFromServer` becomes `fetchMailStateFromServer`
- `_initialize{*}` becomes `_update{*}FromServer`
- `_isModerator` becomes `_isMyselfModerator`
- [REF] Use 'template' pattern design to make Include on
Mail Manager much more robust. In particular,
the flow is always as follow:
1. Initialize internal state.
2. Listen on buses.
3. Fetch mail data from server.
- [REF] Improved workflow for thread window workflow
(Shorter & more readable).
B. Mail Tests
-------------
- [REF] Thread Window Tests crashes with clean message when
there are some thread windows open before running the
tests.
C. (Model) Message
------------------
- [REF] Improved method names for readability purposes
(e.g. `isAuthor` becomes `isMyselfAuthor`).
D. (Model) Thread
-----------------
- [REF] Improved `init` parameters on each kind of thread.
- [REF] 'Thread With Cache' has been renamed to 'Searchable
Thread': it embraces all kinds of threads that can
be used with the search view.
- [REF] 'DM' has been renamed to 'DM Chat' (for clarity).
- [IMP] New Livechat model in the backend.
- [REF] No more direct instances of the Channel class: public
and private channels are now 'Multi-User' channels,
while DM Chat and Livechat are 'Two-User' channels:
This change has been made so that instances of classes
always have direct classes as "leaf" in the Class
modeling. It eases making changes to a certain model
without being too constrained by another model.
- [REF] As a consequence of above changed, the method `isChat`
has been renamed to `isTwoUserThread`.
This is to avoid confusion with the terminology
'chat', which is more like a shortcut for 'quick real-
time conversation'. In other words, the property of
'chat' depends of the way to interact on a thread, not
of the intrinsic type of the thread.
Still, some parts have kept the terminology 'chat',
such as in the systray messagin menu.
- [IMP] Added `message_added` and `message_posted` hooks,
which may be useful to easily hook on those events.
E. Thread Widget
----------------
- [REF] Now uses a `mail.model.AbstractThread` for the
rendering of a thread, instead of a list of
`{mail.model.AbstractMessage}`.
- [FIX] Stick thread scroll height to bottom on new rendering,
if it was previously at the bottom of the thread.
- [REF] Option ORDER has its meaning changed: it now refers
to the chronological order of messages in the thread,
in which DESC means 'from top to bottom', while ASC
means 'from bottom to top'.
- [REF] Improved doc on templates, in particular with the
option `ORDER`.
F. Thread Window
----------------
- [REF] Moved more logic to thread windows, which were
previously in Mail Window Manager.
- [REF] Now hides the thread widget attribute. So instead of
`threadWindow.threadWidget.isAtBottom()`, it uses
`threadWindow.isAtBottom()`.
- [FIX] New received messages when not having focus on Odoo
tab should always make the corresponding thread
windows "passive" (i.e. windows that keep threads
unread until click on them).
- [FIX] Blank thread window (i.e. 'New message' TW) correctly
opens Discuss with 'Inbox' when clicking on 'Expand'
Button in the title
- [FIX] Do not display the composer for channels with property
'mass-mailing' set in thread windows.
G. (Website) Livechat
---------------------
- [REF] Some `trigger` have been turned into `trigger_up`.
- [REF] Some logic has been moved to models (e.g.
`{im_livechat.model.WebsiteLivechat}`), from
`{im_livechat.im_livechat.LivechatButton}`.
- [FIX] New messages should be received in real-time. The
longpolling was broken with a recent refactoring on
bus service (6448420c5d).
Purpose of this commit is to improve the onboarding and the first steps of
Odoo notably when using Discuss and inviting first people to join Odoo.
In this commit we now ask the user to activate desktop notifications. Like
already done in Discuss a message will appear in systray in order to ask the
user to do it. This message will disappear once the user accepts or blocks
desktop notifications.
This commit is linked to task ID 1838588 and PR #25075.
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.
Also roughly called "open chatter in chat windows".
With this commit, document threads can now be detached in a small thread window.
It uses client-side cross-tab window synchronization by means of the local storage.
To detach a document thread in a thread window, click on the document thread preview
in the systray messaging menu when receving a new (needaction) document thread message.
-------------------------
Technical Limitations
-------------------------
1. In order to use this feature, the user must select the Notification Management
'Handle with Odoo' in the Preferences of the User settings (top-right menu).
2. For the moment, only needaction messages automatically updates the thread window. Manual
refresh is still needed for other kinds of messages (e.g. reload document record to fetch
new messages in the document thread).
Server-side code changes are required to receive new document thread message notifications on the
longpoll bus, which would fix the limitations above.
-------------------------
Future Works
-------------------------
1. Receive any new message from the document thread window when it is detached.
2. Log a note from the document thread window.
Task-33118
Alexandre Kühn