the messages in a thread were previously rerendered every minutes to
update their timestamps. This commit only update the timestamps, not
all the message. This will allow us to keep expanded/folded state in
messages without collapsing them every minutes.
[IMP] mail: add read more/read less support client side
Messages are cleaned up and tagged server sides, with a attribute
data-o-mail-quote. This commit replace their content with a clickable
read more link, which toggle its display.
Before this rev., editing the subtypes of other followers was only possible if
the current user already opened a record of the same model of which he is
himself follower.
- extended_chat_window feature in its own files: as it is only available in the
backend, we don't want it in the frontend assets (which contain the 'basic'
chat_window)
- move followers feature in its own files
- creation of the 'mail.utils' module in utils.js
- creation of systray.less to define the style of the mail item and dropdown
in the navbar
- use of chat_manager's search_partner function in PartnerInviteDialog
- some code linting
When loading a form_view with the follower widgets, an RPC was performed to get
the followers info (name, email...), and if the user is one of the followers,
a second RPC was done to retrieve the subtypes.
This rev. batches those two RPCs. Also simplifies read_subscription_data() as
it is now always called with a follower_id.
A few code refactoring as well.
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.
Remove the RPC to retrieve the action_id of the client action as do_action()
can take directly the xml_id, and batch the RPC to retrieve the menu_id with
the initial RPC used to fetch channel slots, emojis...
- 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
Géry Debongnie