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).
Mailing lists (mail.channel) should not send specific notification emails.
Indeed there can be a lot of recipients and customizing each email can
take time to compute. This leads to posting a message on a mail.channel
being very slow.
It is now possible for a model to customize the notification email
recipients computation. The first use is to ensure that mail.channel
encodes recipients using email_to instead of recipients_ids. This way
less processing is performed on notification emails.
This is a manual cherry-pick of commit d4a1eb4435
that was not forard ported. Mail has indeed evolved since 8.0 and its
forward port was not an easy task.
This commit also includes the fix of mail.channel recipients. All are now
considered as equal and receive a simple notification email. No distinction
is done between partners and users. The notification emails for channels
should be as simple as possible.
Problem was that administrators have access to every channels, even private
channels they are not registered to, because when trying to join an existing
channel, the autocomplete proposed every channels accessible for the user, but
didn't filter private ones.
This rev. makes sure to only suggest non-private channels.
Also prevent '|' domain injection to disable filters (odoo/odoo@44e65e72d3)
by using expression.py to build domain.
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).
We should not trust arbitrary arguments from public method to compose a domain
as it is possible to inject '|' to disable filters and be able to search any
channel (mitigated by access rules).
Create a private method and use a wrapper that ignores the domain.
* 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
Searching on res.partners with domain [('user_ids' , '!=', False)]
will currently be translated into a huge "ID IN <...>" query,
with the IDs of all existing users.
On a database with a lot of users, this can be measured
in seconds (e.g. 3-4 seconds with 500k+ users),
leading to significant delays in email delivery.
Using a direct lookup in res.users is more direct and faster.
When editing an email template with the wysiwyg,
the `<` and `>` operators are automatically converted
to `<` and `>`, even for the Jinja2 conditions,
therefore breaking these conditions, and the render
of the email templates.
We avoid to use these operators in the email
template, so users can customize the notification
email template without having an advanced
knowledge on how to edit an email template containing
Jinja2 code.
Besides, the line return at the end of the email template,
just after the `% endif`,
is done on purpose as well: the wysiwyg adds automatically,
at the time of this revision,
`<p></p>` at the end of the email template source, but
this cannot be added on the same line than `% endif`,
otherwise this is considered as Jinja2 code, and it's not.
opw-659113
Do not restrict followers-based alias to members of non public channels.
Otherwise you may have issues defining a public mailing list with a
subscription step. People still wouldn't be able to post on a public
channel using a restricted alias.
message_get_email_values is declared as receiving cr, uid, id. However this method
is an override of a multi method. A decorator has been added to tell that id is
actually a list of ids and avoid list encapsulation issues with the result. This
way the method parameters are not changed.
[CLEAN] mail: removed some unused imports, by the way
This computed field allows to know whether the current user is a channel
member or not. This is necessary to fix the join / leave action button
on channels. It was still based on the followers and has not been updated
with the new v9 model of channel members.
Now that channels can follow documents, restricted aliases are a bit too
restricted. We consider that followers-based aliases accept emails from
the direct followers (message_partner_ids) or member of non public
channels (message_channel_ids, filetered public field). This way we avoid
having public channels added by mistake, leading to information leak.
Before this rev., only the root user was allowed to do so, because some
operations were performed on the channel just after the user had been
unsubscribed (to trigger the unsubscribe notification on the bus, and to post
the 'left channel' message).
The problem occurred when the im_livechat cron 'cron_remove_empty_session'
removed empty livechat channels (a public user clicked on the livechat button,
creating a new channel, but never sent any message in it). The empty channel
was deleted by the cron, but the two records in the mail_channel_partner
relation table (linking the channel with the public user and the livechat
operator) wasn't removed, and the value of their field 'channel_id' was None.
When this happenned, it broke the SQL query of 'channel_search_to_join()', the
RPC call performed when clicking on '+' new to public channels in the client
action, resulting in no result displayed in the dropdown.
With this fix, records in the relation table are automatically deleted when
their corresponding channel or partner is deleted.
- display appropriate message when no results are found in a search
- don't display 'you have been invited' notif when creating private channel
- correctly join when a user was invited in a public channel
- display a message when a user join a channel through an invitation
- don't display subject for message of type notification (still a
mystery why it happens in test.odoo.com for channel of type mailing)
- better heuristic on when to display message subject
- tweak sidebar text color (slightly whiter)
- add ... to the placeholder of the text area in the composer
- invert send and icons for attach/smiley in composer
- don't display 'read less' on expanded messages
- exclude livechat channels from channel mention suggestions
The purpose of this commit is to improve the overall performance of the mention
mechanism of the client action and chatter composer, by pre-fetching some data.
First, the employees are fetched at chat initialization (basically, at web
client initialization), if hr is installed.
Second, when focusing on the composer of a channel, the members of this channel
are fetched. In the case of a chatter, the members are already known as they
are the followers of the document.
When the user types a mention, we first display suggestions from the pre-fetched
partners, and we only perform an RPC when there are no more result matching the
search string. This RPC searches among user, and then partners if there aren't
enough matches.
A few side changes occurred:
- auto_join set to True on user_ids field of res.partner to boost the query
that searches partners that are users
- the '/mail/read_followers' route now returns follower's email as well, as
we need it for the mention;
- a partner can now be mentionned several times in the same message;
- mentionned partner previsualization has been removed, mainly because of
the previous point, but also because it simplifies the code;
- emoji are no more clickable in threads (they are only in the popover)
- correctly update channel needaction counter
- don't display 'New message' notification when the channel in detached
- display in the ui channels that send emails and other channels
- prevent notifications in mass mailing channels
- increase bottom padding in client action thread
This commit concerns DM and livechat channels. Those channels are now
automatically detached on the receiver side. This allows users to directly
reply to DM's or livechats without coming back to the client action.
Note that they aren't detached if the user previously manually closed the
channel's chat window.
The livechat channels returned by the chat_manager's initial RPC were ignored.
Livechat channels thus weren't persistent in the client action.
This rev. cleans the returned object 'channel_slots' so that it only contains
arrays of channels. The additional mapping and partners array were useless as
the information they contained was directly stored in the DM channels.
We now simply iterate on each array returned and add each channel it contains,
including livechat channels.
DM channels are supposed to be pinned on each partner's side when a message
is post in the DM. This didn't work because we checked if the channel is a DM
by comparing its type to 'direct_message', which is not a valid channel type.
Also stop marking the DM as pinned in channel_join_and_get_info() as it is now
useless.
Indeed portal and public users may have to read internal subtypes to perform some
check in the code. However the rules do not allow them to read those internal
subtypes. We have to read some subtypes as sudo then.
`node.get('class', '')` returns a `Nonetype`
in some cases, and, therefore,
`'o_mail_notification' in node.get('class', '')`
throws a
`TypeError: argument of type 'NoneType' is not iterable`.
Replacing by `(node.get('class') or '')` keep the behavior
that was expected, but will prevent to have a `Nonetype`
opw-656508
opw-656753
opw-653965
The read more / read less in chatter has been removed in the new timeline and
then cleaned timeline introduced at cc6d2aa995.
This feature has been brought back at revision 486aab5098.
However a new cleaning removed the feature at revision 2a5f07e0b9.
This commit brings back this feature for the second time. Next one brings free
cookies.
When having a tracking, the subtype description should be displayed. This is
used for tracking linked to a subtype like Task Opened, Task Blocked, ...
This feature was forgotten when refactoring the chatter for v9 and is now
back.
When calling 'set_message_done' on a message which is a needaction for several
partners, the method was executed as root. This was an issue for the triggered
notification, as it was thus always sent to the admin.
For example, when Demo user marked such a message as read, he never received
the notification, but the Admin did, and its notification counter weirdly
decreased, while the one of Demo user remained the same.
- vertically center date and messages separators in threads
- remove notifications in DM and livechat
- order mail demo data so that messages appear ordered (they are ordered by id)
- make sure that DM are pinned (they weren't on the receiver side)
- don't display DM until a message has been sent
- validate message body
- undo snackbar fine tuning
- fix Firefox scroll bug on sidebar rendering (the scroll position was often
lost when the sidebar was re-rendered, seemingly because the width of the
thread changed for a brief moment)
- put the mentionned partners and the attachment above the composer
instead of below
- debounce some links in thread.js to prevent double loading views when
double-clicking
- readd the # in front of the channelname of the title of the client action
- give the channel_id to the thread in a chat window, so it does not
display the channel name everytime it displays a message
- correctly close dm chat window when the dm channel is closed in the
main sidebar
- simplify the help messages when a channel is empty
Mainly concern the client action:
- Display needactions per channels
- For all channels except Inbox, clear needactions when opening the channel
- Add snackbar to undo needactions clearing
- Display a separator between read and unread messages in threads
- Fix active channel (for Inbox and Starred) display in sidebar
Various minor changes in chat_manager:
- Code refactoring of bus notification handler
- get_channel() don't fallback anymore on first channel
- display star/mark as read icon next to the message title instead on
the far right
- display unstar all message in channel starred
- enable/disable the 'unstar all' and 'mark read' buttons depending on
the number of messages in the corresponding channels
- display star on the left sidebar in 'squashed messages'
- tweaks to padding in client action
- display hash in channel name in lighter tone
- light opacity in sidebar
- star icon in message sidebar is clickable + small less refactoring
- message sidebar is aligned with the message now
- messages are not squashed in inbox/starred
When we refresh, the bus will send the last notifications since the last
50s, so, the browser will receive notifications from a channel that we
already left. This commits tries to fix the issue by sending
explicitely the information that a channel was unsubscribed.
Also, and this is touchy, it ignores messages received in a channel that
it is not subscribed to (before, it joined the channel)
Also, it will synchronize channels opened and closed in various
tabs/browsers.
in some cases, it is possible to call the method
channel_join_and_getinfo when the user is already in the channel. This
may (and did) cause issues in some unrelated code. This commit
guarantees that this codepath will avoir creating another entry.
Another way to achieve this result is by adding a constraint on the
model mail.channel.partner, but this is in 9.0, so we must be careful.
Aaron Bohy