When posting on a thread the user can be auto-subscribed to its default
types. But if the user has previously been subscribed to other subtypes,
those are lost.
With this commit, user mentionned (@{username} in message) or added as
follower for default subtypes are not subscribed if they were already
followers of the record.
So if default subtype is "Comment" and user was only following subtype
"Alarma!" (by checking it and then un-checking "Comment"), then if the
user comment:
-> before this commit, the user would then follow subtype "Comment" and
not follow anymore "Alarma!"
-> after this commit, the user would follow the subtype "Alarma!"
closes#12008
opw-669127
opw-673766
- The "From" should not be the administrator user but
the postmaster/system, and should be an address that
ignores double-bounces. Using the default bounce
email accomplishes both.
- The "To" recipient should be the "envelope from"
sender when available, usually as provided by
the "Return-Path" header set by the upstream MTA.
If not present, fall back to the "From" of
the original email.
- adapt tests to verify the behavior wrt Return-Path
The possibility to choose a subtype when logging a note was added with the
activities mechanism in CRM. However as the user should not use the chatter
but a dedicated wizard in order to do this, the dropdown is removed.
The internal subtype mechanism is kept. Only the possibility to log something
else than a note through the chatter UI has been removed.
When having multiple aliases matching a record, take the first one coming
in the order instead of the last one. This way the defined order is effectively
taken into account.
Finally add support of CIDs in incoming emails. Inline images are recognized
and added as attachments. Image links are updated from src=cid: to src=link
using the /web/image controller.
It has been decided to keep the image in atttachments instead of putting them
in base64, like proposed in various PRs. Indeed we prefer to store this data
into the attachments instead of directly putting it in the mail_message table.
Moreover this enable the display of attachments in the chatter and record views.
`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
When performing automatic tracking it is now possible to automatically send
emails based on a template. This template can either be a qweb template
using its xml_id or a MailTemplate using its record.
This is simply implementing directly in the mixing a feature already present
in recruitment and soon to be added in task, issues or helpdek.
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.
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).
_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.
_message_track is encapsulated in a method that calls it in batch. The purpose
is to ease the tracking to work in batch. Moreover future improvements in mail
will use this method and will be able to work in batch.
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.
* 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.
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
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.
>
> This merge adds some basic data to notification emails headers. It contains the related
> record of the notification. This allows users to classify / perform action based on
> headers.
>
> Headers :
> - X-Odoo-Objects: list of records
> - X-Odoo-db-uuid: database uid
In task and issue, we had the parent project and the tags in the headers.
`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
Christophe Simonis