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
This makes every template holding images crash. As this feature will shortly be
fixed in 9, let us temporarily comment its use and wait for the forward port of
the fix.
- 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
Thibault Delavallée