This reverts commit a8239cd as the navbar dropdown recently introduced now
offers a quick access to channels without coming back in the Discuss App.
Moreover, this commit emphasizes the notifications navbar icon when there are
unread messages (or at least, it mutes it when there isn't).
Some UI changes:
- Unread messages in chat are now displayed as needactions in the Discuss's
sidebar (badge with counter of unread messages, instead of simply bolding the
channel name).
- The counter displayed in the navbar is now the sum of needactions and total
of unread messages in chat.
- The counter displayed next to Inbox is still the needaction counter.
For consistency between tabs/browsers/devices, the channel_seen info is now
broadcasted, meaning that every tab/browser/device will be noticed.
Also now correctly increment the unread counter of a channel if the received
message is a needaction.
The navbar notification is now a dropdown containing a preview of all pinned
channels (except Inbox and Starred), channels with unread messages being on the
top.
It allows to quickly detach a channel without going back to Discuss.
The channels preview fetching is performed only once, and it is done in
background without blocking the whole UI (using shadow option or session.rpc()).
Also fixes a synchronization problem between server and client about the folded
state of channels (the info wasn't stored client side, so it produced weird
situations, e.g. unfolding a channel didn't actually unfold it).
Former algorithm to display chat windows was pretty basic: each window was
positionned 5 pixels to the left of the previous one, starting from the bottom
right corner of the screen. Thus, when there were too many chat windows to fit
in the screen, they overflowed to the left.
This rev. handles this case by hidding overflowing chat windows and making them
available in a dropdown positionned 5 pixels to the left of the last visible
chat window.
Using some templates it is possible to have odoo buttons directly in the
mail_message body. Hide them in the chatter as this is more noisy than
usefull.
when the bar asking for notification permission appears, it can cause
two scrollbars to appear in the client action. This commit moves the
notification bar inside the chat content, which solves the issue.
Except for messages, activities on a document like internal notes posted
trigger notifications to partners and channels following the corresponding
activity's subtype.
Rev. 69ed801 rightly re-introduces a filter on followers to prevent notifying
more partners than necessary. Unfortunately, this filter doesn't take into
account channels, which are thus automatically removed from followers to
notify, whatever the subtypes they follow, e.g. internal notes on a document
don't appear in channels following the 'Note' subtype of this document.
This commit makes sure that channels always pass through that filter, but warns
users that public channels should probably not following internal subtypes.
Also makes the edit subtypes dialog html valid (li's must be inside, e.g., ul).
The chatter composer extends the basic composer to, among other things, add
a button to open the full composer next to the button to add an attachment.
In a recent commit, the basic composer template has been slightly changed and
the buttons have been extracted in a sub-template, which seems to break the
template inheritance (the xpath refers to one of those buttons).
This solution simply removes the sub-template and duplicates the code.
This commit introduces native notifications (if available) to the
discuss application.
Those notifications will only appear if the user grants the permission
for that. A notification bar will appear in the discuss application if
necessary to prompt the user.
Also, it always is the master bus that will be the one sending the
notification.
For this change, it was necessary to be able to detect if the user has
the focus on some other odoo tabs. For this reason, the bus was
extended.
Two RPCs were performed by the chat_manager on webclient launch. One of them
was about emojis, and recent messages received in the past 10 minutes in
detached channels. This RPC has been removed as the emojis fetching can be
done in the other RPC (mail/client_action), and the recent messages are not
useful since the refactoring of mail and the introduction of the chat_manager.
Commit 5d1b323. re-enabled the user presence updates and notifications.
Unfortunately, it showed poor performance due to the high frequency of bus
notifications triggered on our instance (~600k users).
In this rev., we don't trigger notifications on presence changes anymore, but
we rather send the presence of users we have a DM open with, at the end of each
poll period. For performance reasons, we ensure not to do that more than once
every 30 seconds.
We also refined the detection of the 'away' status client side. 'Last presence'
timestamps are stored in the local storage, and the current inactivity period
is sent at each poll. Those presence timestamps now rely on browser activity
detection (click, keypress... events) rather than on the focus on Odoo tabs.
Finally, we removed the no more necessary cron introduced in 5d1b323.
In Discuss, when the user opens a channel, the composer was the same,
regardless of the channel type. This is fine for chat channels, because
we expect mostly small one liners to be written. But for mailing
channels, it is a problem: it is too easy to send a mail to everyone
just by typing ENTER, when the user wanted to go to the next line.
This commit introduces a new widget, the extended composer, to be used
for those channels. It allows the edition of the subject line, and
don't sent messages when the enter key was pressed.
Before this rev., no notification was sent on the bus when the user presence
changed. Thus, the bullets displayed in Discuss were never updated and stayed
as they were on the initialilization of the chat_manager (on webclient launch).
This rev. makes the bus.presence notifications work, and handles them client
side.
Moreover, the disconnections detection is now performed at each poll (with a
maximum of 1 per minute), instead of randomly (1/100 chance) at each poll, as
it scales better than the former solution. We also added a cron that performs
this check every 5 minutes. It is needed to detect that the last connected user
just disconnected (useful for visitors in the website, trying to talk with a
livechat operator).
Also, the 'away' status is now handled client side, as it makes more sense
that way (being away at each poll, e.g. every 50seconds, during 10 minutes
doesn't mean that we didn't come back between two polls).
Finaly, in bus.js, CrossTabBus, we moved the code writing in/reading the local
storage after the tab registration as this code depends on the fact that the
tab is the master tab or not (and this is known only once the tab is
registered).
This rev. was necessary in stable because the livechat uses the user status to
detect if there is an operator available, and this was often inaccurate.
Moreover, it improves the user experience of the chat in the backend.
The traceback ocurred when the operator closed a livechat channel chat window,
and then unpinned it from the sidebar in Discuss. Then, if the visitor sent
him a message, the channel was automatically re-pinned to the operator, who
received two notifications: the first one being the new channel info and the
second one the message itself.
The channel fold_state being 'closed', the window manager was trying to close
it again, which produces the traceback as the channel didn't exist in the JS
cache anymore (it was re-added to the cache when processing the message
notification, so just after).
Anyway, closing this channel was useless as, even if it was in the cache, it
would already been closed. So this rev. simply checks whether or not the
channel is in the cache before trying to close it.
The problem was that users couldn't write characters like <, > in their
messages because the messages are html (e.g. '3 < 5' resulted in '3' because
this wasn't html valid so the second part was trimmed).
Because of mentions, we can't force messages to be plaintext (mentions are
processed and replaced by html links before the message is stored in DB).
The solution is to escape them just before processing the mentions. In the case
of chat windows, we must be careful because chat windows are also used for the
livechat, for which messages are plaintext. So the escaping should be done for
chat windows in the backend, but not in the livechat.
* chat windows:
- input was kicked out of the window on chrome 43
- don't animate if folded by default (e.g. after a refresh)
- width and height 100% like in the frontend
- z-index to make sure that they are over bootstrap active btn,
but below notifications, and modals
* chatter:
- internal note: send button renammed to 'Log'
- send button is the first button again
- remove annoying form view widget's tooltip
* client action: focus on composer on channel change
There was a weird bug on chrome when there was a scrollbar in the sidebar, as
the right part of the client action overlapped that scrollbar. The problem was
seemingly linked to the use of flex, which is removed by this rev.
Courtesy of QSM
- don't display user name in chat windows
- scroll to the new messages separator if it exists (in client action)
- increase sidebar width
- add correct link href in threads
- hide chat window in mobile mode
- mail: ignore o_mail_redirect or o_channel_redirect, but redirect anyway
- display full content of messages in Discuss
- no content helpers in inbox and starred improved
- mark as read tooltip instead of mark ad done
- decrease font size in chat windows
- increase chat windows dimensions
- display avatars in chat windows
- chat window background is now white
- notes are displayed with a darker background
Clicking on this icon redirects to the client action (for now at least). By
quickly clicking several times on it, we try to restore the scroll position of
a channel that not yet exists. This rev. prevents from getting a traceback in
that case.
When the delimiter '@' is used in the composer, a regular expression is
built in order to suggest followers. However, if this regular expression
is incorrect, it causes a crash since RegExp will throw a syntax error.
Since a new regular expression is built for each new character the user
types, this situation can occur very easily. For example, typing '@('
will cause a crash.
This fix replaces characters which may easily lead to a syntax error by
a space.
Aaron Bohy