- 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
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.
`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.
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.
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.
`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
- remove / udpate some paddings. Indeed some part of the notification emails
are badly aligned.
- postprocess the notification email to remove the content coming from odoo.
This ensure that action buttons present in some emails are not forwarded to
other people, notably customers. This is done by adding a div holding the
whole notification emails, with a summary = o_mail_notification. A summary
is used instead of a class or id because some html clients (like gmail)
strip classes, ids, ... summary seems to be kept in several clients.
The message_last_post mechanism was introduced to have a trigger for
automated actions, but for some reason we do not use it. Moreover, it
interacts badly with the bus.
Because of the message_last_post update, concurrent transactions can
fail and be rollbacked. This is an issue because the bus commit the
transaction after writing the messages. This means that some messages
can be duplicated, and the more users are chatting, the more frequent
this will happen.
Since we don't use this field, it could be removed from the models, but
we are in a stable release, so we need to keep it for now.
Posting message is done in 'html' since mention add html tag in body. Clickable url is done server to allow link in mail and chat message. Plaintext are transform into html, and html message are simply parsed to transform url into clickable link.
- fixed computation of needaction flag (typo)
- fixed order of auto subscription and message tracking: first subscribe then
track. This way messages are send to newly added followers.
- added tests in CRM to ensure this behavior works by updating the already
existing test and using the mail test class
The stdlib version of the json library is more recent than the 3.5.3
version we are pinning in `requirements.txt`
There is no reason to use it.
Closes#6940
When creating a document a message is posted (ex: 'document created') and the track field users are auto added as follower and notified with the last posted message (like the just create message). So the author was notify of the creation of its own document.
The problem did not appears using form view, beacause when the mail.message were reloaded, the thread was mark as read, so the partner (author/creator) was directly removed from the needaction_partner_ids field. The issue happen when loading the demo data, generating many needaction for the admin user (creator of most of the document).
This bugfix remove the current partner from the new follower to subscribe and to notify with the last posted message, as done when a message is posted (in _notify method of mail.message).
Create `message_post_with_template` helper method to factorize the simulation of a mail.compose.message wizard.
Also, fix the generated attachments of mail.compose.message wizard by returning ORM command (6, 0, ids) instead of the list of attachments ids. In order to standardize the behavior of the wizard, and since the ORM support command assignation in onchange api.v8, all the x2many fields of the wizard return a command.
FYI, that was tde's idea !
This commit add instant messaging features in mail module to make it a real team collaboration tool. Lots of these new features will replace Timeleine view (which is not removed in this commit). Many files have been moved, split or created for a better structure.
- My Channels : A user can be member of channel (mail.channel). These are discussion group, but also an aggregate of notification. Setting a channel as document follower, it will receive all the message (of the chatter) in real time, as information stream.
- A new Inbox : this aims to replace the timeline view. The user will see its channels grouped by 'slot', and receive the message in real time. Jump to the form view, invite people, create private discussion group, talk directly to another employee, ... are the main features. Your message can still be starred. The 'Inbox' will only contain your needaction.
- Needaction concept : a needaction is a message calling you to do something. If you follow a document as a person, the posted message will be 'needaction' for you. It can also be a message where you are mention with a '@my_name' (this feature is not added in this commit).
- The chatter doesn't change so much. It still allow you to see the discussion about the document, to star some message, and treat your needaction.
- Chat : the only way to have a minified conversation is from the Inbox Client Action. It allow you to keep an eye on a channel when working on document.
- Compose Message : it is now common to the Inbox, and the chatter. It offers shortcode substitution, attachments management, and optional subtype.
- UI : the chat window has been clean, they have a new look now.
To do so,
- Chatter code have been completely rewrite, independently of timeline view
- Add 'bus' as mail dependency, to insure real time
- A mail.message is broadcasted on the bus channel (db, mail.channel, channel_id), and a channel header on (db, res.partner, partner_id)
- Extracting mail_thread mixin used for Chatter and ChatMailThread (Inbox client action). This uniformize the programming structure with the server side
- Clean CSS style and use LESS instead of CSS
- Define a new messafe format (message_format method in mail_message.py), compatible with fetching and broadcasting
- Apply guideline coding conventions
This commit also break the module im_livechat, since im_chat models don't exists anymore and will be fixed in the next commit.
Thanks to Thibault Delavallee (tde) for the long debates and precious advices, Richard Mathot (rim) for the support, Simon Lejeune (sle) for the client action layout, and the Usability Team (apr, lle, bst yti) for the long testing.
Conflicts:
addons/mail/models/mail_thread.py
Notification emails have been redesigned. They notably include buttons
allowing to perform some action directly from the email.
The notification creation and sending has been partially rewritten
and improved. The purpose is to lessen the number of rendering to perform
when sending emails to recipients. Recipients are first categorized into
groups. Basic groups are partners and users. The notification template
is then rendered twice, one for followers and one for not-followers. In most
cases there will be few rendering to perform. Through inheritance it
is possible to further categorize users. For example HR users / officers
that have approve / refuse buttons in their email.
A custom data structure is used to store data about buttons and actions.
URLs, follow / unfollow are added in the structure and used in the
template to render the email for a given group.
New routes are added in mail. Those allow to perform some action, like
going to a form in create mode, following / unfollowing, executing a method,
sending a signal for a workflow. Those routes are for users only and rely
on classic access rights.
A generic route for viewing records is added. It replaces the old redirect
action. According to some specific action given by the already-existing
get_access_action, the record will be visible for everybody (forum, blog)
or restricted (going on the Inbox / login / form view, according to access
rights).
The next commit will add the various inherits necessary to add the actions
in the main addons.
Main changes :
- mail.notification model is removed. People do not receive notifications
anymore. Instead two ways of following documents exist
- using a channel; messages will be displayed on the channel itself
in a near future commit
- following with its partner; messages will all be considered as
needaction, using a new m2m table. People should receive less
needaction messages by following less records by themselves.
There is no more read / unread state anymore. Instead only needaction
messages are considered. Todo (Favorites) messages still exist, and are
stores on a new m2m table instead of using decorated notifciations.
- the main filter for documents is not message_unread anymore, but
message_needaction. A lot of views and filters have been updated
accordingly.
- the vote feature has been removed
Followers can now be partners or channels. Partners following a document
will receive needaction, as previously. However people can follow documents
through channels. Members of a channel are able to listen to a stream
of messages using the channel. Those messages do not create needaction
messages. It is therefore possible to follow documents without receiving
too much notifications. For interesting documents subscribing with its
partner will create notification.
message_follower_ids fields is udpated. It is now a many2many to
mail.followers, not to res.partner anymore. A subscription can be either
a partner (partner_id) or a channel (channel_id).
Some access rules have been updated accordingly.
can lead to issues when trying to compute followers.
This case appears in the onchange mechanism. Indeed it may
manipulate temporary and/or new records, not having an
ID. In this case the computation of followers is not
necessary anymore.
Olivier Dony