Problem is that when someone is mentionned in a channel he doesn't belong to
(public, private or DM whatever), the message only appears in its Inbox and
he can't know where it comes from nor reply. This is thus very confusing.
With this rev., in Discuss, one can only mention members of the channels.
In the chatter, anyone can be mentionned like before, as when the message
arrives in the Inbox, there is a link to the associated document.
When using multi tabs or browsers, the 'New messages' separator in threads was
sometimes wrongly displayed (displayed over messages already seen in another
tab or browser).
Problem was that since rev. 617968c61, we consider sent messages as read client
side. This has been done to avoid to indicate that a channel has unread
messages e.g. when this channel is a follower of a chatter in which we wrote
a message.
This change has as consequence that we don't perform the 'channel_seen' RPC for
messages sent. At each refresh, the server sends information about pinned
channels, especially the unread counter, which was thus sometimes incorrect.
This rev. simply doesn't take messages we wrote into account when computing
the message_unread_counter field.
Also correctly display the 'New messages' separator in threads, by automatically
skipping messages we wrote (i.e. it is now displayed above the first message m
with m.id > last_message_seen_id and such that we aren't the author of m).
- limit partner search to 10 in new message's chat window to prevent overflow
- prevent negative needaction counters (may occur in multi-tab, with
needactions received during an inactivity period)
- remove <pre> tag when computing messages' preview for the messaging dropdown
as they break the layout and add 'overflow: hidden' on o_mail_channel_preview
just in case
- rename 'New message' button in Inbox into 'Send mail' as it was confusing,
and adapt .pot file accordingly
- focus on composer when opening a chat window
- break lines in threads to avoid horizontal scrollbar (credit goes to qsm)
- correctly apply rules on <p> in threads
opw-667235
sometimes, the web client receives unsubscribe notification and an extra
notification on that channel. This is then followed by an attempt to
rejoin the channel that we just left. This commit prevents that
situation to occur.
For that, it needs to know the notifications received by the bus in one
batch, not one at a time.
The client action had a weird issue: going back from a breadcrumb to the
client action made the searchview (filters/favorites) buttons disappear. This
is caused by a weird behavior of the control panel. This fix is the safest
for now, but working on the control panel behavior would be a better long term
solution.
The message body must be inside a tag div because when the message was short
with a @author, there was no tag div around the body and it was displayed
inine.
opw:666840
Two composers are appended to the client action: a basic composer and an
extended one used in mass mailing channels. Emojis are rendered in a container,
and when the user clicks on the emojis button, this container is shown.
The problem came from the fact that this container has the same classname in
both composers, so for both composers, the emojis were rendered in the same
container, producing an empty container for one of the two composers
(in this case, the basic one).
- don't add 'New message from' in the title of notifications when an
author name is defined
- use a simple O icon instead of the full Odoo logo when a notification
is natively displayed
- don't scroll to bottom if the thread is not already at bottom
- don't mark a channel read if thread is not at the bottom
- add # in front of channel name in chat windows and in invite dialog
- accept anonymous names in channel (for ex, livechat channels)
- always go to the next line with shift+enter
- always send message with ctrl+enter
- pressing enter sends message or go to next line depending of context
- don't allow to detach mass mailing channels
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.
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