Before this commit, when receiving a new message from a hidden chat
window, it was making it visible. Because of this, if we had focus
on any other window, the focus was lost. Even more annoying, if we
had focus on the left-most visible chat window, it moved to hidden
menu, so that new chat window takes its place.
This commit fixes the issue by keeping new chat windows hidden
on receiving new messages, in case there is not enough available
space.
Task-ID 2026101
closesodoo/odoo#34291
Signed-off-by: Martin Geubelle (mge) <mge@openerp.com>
Revision on https://github.com/odoo/odoo/commit/cd34f6de727d5b3858420cff3c9d3c5995c4e75c
Before this commit, when receiving a new message from a new DM
or livechat, the newly opened chat window was automatically
focused and marking messages as read.
Chat windows that are automatically opened without any user
interaction, such as when receiving a new message from a chat,
should not be focused. Those chat windows are "passive", and
the user must click on them in order to have focus and mark
messages as read (the chat window is no longer passive as a
result). The bug has been introduced by the refactoring from
the commit above.
In fact, there was a very short period of time during which the
chat window was passive. However, due to the way chat window
server-side state synchronization works, the chat window was
automatically closed then re-opened. This resulted in some visual
flickering of the chat window ('open' > 'close' > 'open'), and
the conversation was automatically marked as read. This was a
consequence of the actions 'open' > 'close' > 'open' that removed
the passive property of the chat window.
Chat window server-side synchronization relies on a notification
that tells the state of the conversation. Due to bad design, this
notification had exactly the same format as the one for notifying
all browser tabs of a newly joined conversation.
This commit fixes the issue by distinguishing "channel join"
and "chat window state" notification, so that the former is not
treated as a chat window notification. It fixes the problem
because it was precisely the "channel join" notification that caused
the chat window to close and loose its passive property.
Task-ID 1914735
opw-1914371
closesodoo/odoo#29223
Before this commit, DMs had the prefix '#' in their
displayed name (e.g. '#Demo User').
This commit fixes the issue by putting this prefix
only on non-chat DMs. In particular, mailboxes, DMs
and Livechats no longer show this prefix. This change
is also visible in the breadcrumb of the discuss app.
Task-ID 1911738
Have a user A having the focus on the search bar, minding his own business
Have a user B send a direct message to user A
Before this commit, the chat window on user A's browser took the focus manu militari
After this commit, the focus stays on user A's search bar
OPW 1911553
closesodoo/odoo#28915
Revision on https://github.com/odoo/odoo/commit/cd34f6de727d5b3858420cff3c9d3c5995c4e75c
The commit above consisted of refactoring the JS mail module.
A small regression was introduced on messages linked to a document
from a chat window: it was no longer displaying the link to redirect
to the document that this message originates from. This issue was
only isolated to chat windows: it was working fine in the Discuss app.
This commit re-introduces the displaying of the document link on
messages from chat windows.
Task-ID 1910119
Before this commit, a moderator of a moderated channel could see
commands on 'pending moderation' messages in a chat window, although
none of them work in chat windows.
Those commands only work in Discuss. Making them work in chat windows
is not trivial, because some code must be redesigned for this.
This commit disables moderation commands in chat window. Moderators
of such channel now see 'Pending moderation' on such messages in
chat window, and mouse-hovering on this annotation tells the user
to moderate those messages in the Discuss app.
Task-ID 1887963
Definition of '(non-)passive' thread window:
Thread windows can be either 'passive' or 'active'
(default: 'active').
- When opening a thread window in 'active' mode, the messages
are marked as read, and the focus is on the thread window.
- When opening a thread window in 'passive' mode, the messages
are not marked as read and there is no focus on the thread
window. Messages are kept unread until the user interacts with
the thread window (e.g. by clicking on composer).
When the user intentionally opens a thread window, it should
be open in active mode. However, when a thread window is open
without any user iteractions, it should open in passive mode.
The later case is useful in some cases. For instance, when
receiving a new message from a DM conversation, it should
automatically open the corresponding thread window. However,
it should not automatically mark messages as read.
This commit contains 2 bug fixes:
1. When receiving a new message on an active thread window,
it no longer increments the unread counter.
(When the focus is on the composer of the thread window,
the user is immediately reading newly received messages.)
2. When receiving a new message from an unpinned DM conversation,
the newly open thread window is always passive.
(This was not the case before, so when receiving new messages,
it did not increment the unread counter.)
1. Removed `getLocalMessages` method in mailbox, and replaced
with an override on `getMessages`.
(This method was used before the distinction was made
between `getMessages` and `fetchMessages`)
2. Removed unused method `_warnUpdatedUnreadCounter` in
abstract thread window.
(Leftover from an early POC)
3. Set the default value `''` for the status of a thread.
(The method `getStatus` should always return a string)
4. Enforce default value `false` for detached status of channel.
(The method `isDetached` should always return a boolean)
5. Improve readability of some tests.
(removed useless variables and/or redundant code)
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.
Alexandre Kühn