As it's done few lines below,
in `set_message_done`.
The user could have a notication associated
to a message he has not, or no longer, the
write access, but he should still be able
to mark it as read.
opw-671188
When a specific SMTP server is set on a mail template, it is never used
when the mail is sent. There are two reasons:
- `mail_server_id` is a read-only field set by an onchange. However, a
read-only field is not sent to the server, so the information is lost.
- The information is stored in the context of the object `Mail`, but it
is never used. Moreover, when the method `message_post` is called, the
`Mail` object is not used to post the message, so the information is
lost again.
The fix includes two parts:
- the `mail_server_id` field is not read-only anymore. Actually, there
is no reason to make it read-only.
- the information is stored directly in the mail values and used at the
appropriate moment.
Fixes#6554 (from v9.0)
opw-669958
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.
`write` expects a `dict` for the `values` argument,
`part[record.id]` is a list of commands to add new
followers.
See the returned variable `specific` of the method
`_add_follower_command` in `mail_followers.py`.
Surrounding `part[record.id]` with a `dict` with
`message_follower_ids` has probably been
forgotten by oversight.
`gen` and `part[record.id]` have actualy the same
syntax, and the `write` done with these variables
should therefore be called the same way.
opw-669376
Before, every user was set into this group. It means that a portal
user received elements in his mail context, like the buttons to
open a document or to follow it. Now, only the employees will
receive this kind of information
Two problems occured:
- when the user hadn't seen any messages of a channel, the seen_message_id
was null and doing seen_message_id < msg.id to retrieve all messages
received after the last one seen didn't return any message (null < x is
always false)
- messages sent by visitor on the livechat doesn't have any author_id, so,
again, doing msg.author_id != partner_id is always false, and as a
consequence, server-side, the messages sent by visitors were always
considered as read
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.
This allows linking databases to contracts in the central
contract registry, and automatically updating local databases,
simplifying the registration procedure for users.
Closes#10323
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).
The mail template rendering system use "autoescape" for subject, body,
email_to, ...
Using autoescape is good for the body, but for the subject it means
variables insertions have to be marked as safe.
This commit add another environment without autoescaping enabled for the
subject field.
From https://tools.ietf.org/html/rfc2822:
The "Subject:" and "Comments:" fields are unstructured fields as defined
in section 2.2.1, and therefore may contain text or folding white space.
2.2.1. Unstructured Header Field Bodies
Some field bodies in this standard are defined simply as "unstructured"
(which is specified below as any US-ASCII characters, except for CR and
LF) with no further restrictions.
closes#10547
opw-659231
opw-666801
opw-665863
when a user is disaninactivated, it makes sense to disaninactivate his/her
corresponding res_partner. This had the unfortunate effect of changing
the result of the channel_slot call for the direct messages with this
user. As a result, the discuss interface was not happy. This commit
does what it needs to keep the discuss interface happy. That's what we
want, right?
_mail_mass_mailing attribute is evaluated at server launch (with no context) so
the attribute is never translated.
Create a new method in mail_thread to translate again the term at evaluation but
with a correct context.
Thanks to the _(...) in the attribute definition, the proper term is exported
and present in .pot file.
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.
Géry Debongnie