For a message to be considered as a private message,
the message must have:
- `no_auto_thread` set to `False`
in other words, it must not be attached to a thread
- no `model` or `res_id` must be set on the message
meaning the message is not attached to a specific
record thread.
See `_get_message_id` in `mail/models/mail_message.py`.
Before this revision, the mails sent from
`Discuss` > `Send mail` were not regarded
as private messages,
but as a kind of mass mailing messages,
with a `reply-to` wrongly set.
Any attempt to reply to these mails
failed with a delivery failure notification.
This was because the `message-id` of these messages
contained `reply-to`, and such message-ids are
treated as a special case in the messages routing
(basically, the match on the mail references is disabled
for these messages containing `reply-to` in
their message-id).
opw-669241
The button 'mark all as read' used to mark all messages as read, which
is not usually what the user wants when there is an active filter in the
search view. This commit make sure that the domain is send to the
server and used correctly.
The problem was that mentions weren't correctly erased with DELETE key (in some
conditions), or when replacing mention text. When this happened, the mention
didn't appear in the message, but the message was even tough sent to the erased
mentioned people.
With this rev., we don't try to detect erasing on the fly anymore, but we
rather validate mentions before sending the message with the content of the
input.
opw 669362
When the user can't read the model res.partner, former code tried to determine
whether or not the user was follower of the document. This was wrong for three
reasons.
First, it performed an RPC to get the partner_id of the current user, but this
info is already stored in the session so the RPC was useless.
Second, the partner_id isn't helpful to know if the user is a follower because
everything we have is the follower_ids, which aren't ids of the res_partner
model, but ids of the mail_follower model (compare apples and oranges...).
Third, we anyway didn't use that information at all as the button indicating
whether or not the user is a follower wasn't displayed.
This rev. simply removes that useless RPC and only displays the count of
followers as previously.
- swap reply-to and mark-as-unread buttons in threads
- remove blockquote from stripped html in channel previews
- readd padding to no-content message in threads, also to no match found
message
- add 1 to chat window z-index to prevent control panel buttons to show
through it
On printing, the announcement bar URL was displayed
in the printing result.
e.g.
`https://services.openerp.com/openerp-enterprise/ab/register/...`
was displayed at the top of the print.
This is related to the revision 50a4ca31f8.
This is due to this simple typo, the according CSS rule was
never applied because of it.
This bar was never displayed as the remote css was always empty.
When using the enterprise web client, the printing stylesheet show the
target of links (<a> tags) between parentheses, including the one from
the annoucement bar that should be kept hidden.
When a new message arrives in a DM or a livechat, the channel is automatically
open in a chat window if we aren't currently in Discuss.
Don't apply this behavior in mobile and we probably don't want to see a full
screen chat window everytime someone sends us a message.
Thus also remove the 'Detach' button in Discuss's control panel as we can now
directly detach channels with the messaging menu.
Also removed unused handler on 'messages_read' since rev. 30c26d7.
When a new message arrived in a non pinned DM, the unread counter was
incremented twice ; once because the channel info (along with its unread
counter) was fetched from the server as the channel wasn't in the JS cache yet,
and once when adding the message in the JS.
With this rev., we only increment the unread counter when a new message arrives
if its channel is already in the JS cache.
Problem occured when the first call to get_channel_preview was directly
followed by others, before the channels_preview_def was resolved. In that case,
the other calls all returned an empty array, as only the channels_preview
array was only filled with the RPC result for the first call to
get_channel_preview (the one which initiated the RPC).
Those items might have been rendered and inserted into the DOM before the chat
manager initialization was completed. As those items rely on chat manager's
data, they should wait for it before executing their action (inbox redirection
and channels preview display).
- discuss notifications are always sent natively if possible
- clicking on native notifications focus the tab
- clicking on native notifications closes them
- granting notification permissions will display a confirmation
notification
A missing feature in discuss was the possibility to directly reply to a
message from a channel without opening the document. This commit add
that feature. Now, there is a small 'reply' icon in channels (including
inbox/starred) if the message comes from another document. This icon
opens an extended composer, which will post the message in the document
chatter.
Commit c04103f re-renders the thread every minute to update messages' date.
As a consequence, the expanded messages are lost (they are shortened again).
This rev. makes sure to keep those messages expanded.
Messages of type 'notification' and whose model is 'mail.channel' are
considered as 'system notifications'. This is the case of 'join/left' messages.
They aren't taken into account when computing unread messages anymore.
Also use the same heuristic to decide whether or not to display the message's
star, so from now on pure notifications (not system notifications), like status
change on a document, can be starred.
Clicking on that item redirects to the Inbox in Discuss.
The messaging menu's counter is now the number of conversations (public or
private channels, dm and livechat) in which there is at least one unread
message. Moreover, it is emphasized when one of those conversations is a chat.
Also make mass-mailing channels available through the messaging menu (for
consistency as its counter takes those channels into account) and allow to open
them in chat windows without input.
Message's body is kept when switching from 'New message' to 'Log a note' since
rev. f35b48aa. However, mentionned partners or channels were lost. This rev.
makes sure to preserve both message's body and mentions when switching between
composers.
- don't print chat windows
- add missing 'width: 100%' on composer and Discuss sidebar inputs (required
for community edition)
- center the Discuss sidebar inputs
- Discuss sidebar items layout: one line, text ellipsis if name is too long
- hide chatter in 'create' mode (messages wrote in the chatter need a res_model
and a res_id, the latter is not yet existing if we are in 'create' mode)
- revert 2d2dacc: print chatter by default (classname 'hidden-print' can be
used for specific models for which we don't want the chatter to be printed)
- thread: ensure the displayed message's date is in the past
- re-render threads every minutes to update dates
- don't squash messages in mass mailing channels
The default behavior of session.rpc is to block the ui if it is not
completed in some short delay. This is not really good for various
types of rpcs. The discuss application is actually doing quite a lot
under the hood, and blocking the ui for some of those use cases does not
make sense (exemple: marking a channel as seen)
- prevent concurrent opening of the chat window
- take into account the placeholder value of the livechat session record
- don't send welcome message if empty
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).
Goffin Simon