Currently partners have a boolean field to choose whether to receive
notifications only in their Odoo inbox or to receive them in their inbox
and by email. This leads to several issues :
* if a customer is configured to not receive emails he will not receive
any notification on sales orders, leads, ... This is not clearly
indicated to the salesman and it is not easy to know how to change
that behavior
* if an user chooses to receive emails and does not use its inbox a lot
of notifications stay in Odoo. The user has to manually set them as
done to make them disappear which is redundant.
This commit changes that behavior. From now on customers will always
receive all notifications by email. Indeed Odoo is not a customer oriented
mailbox. Moreover sales orders or discussions on leads send to customers
should always be sent by email as it is the standard communication
mechanism. Users will be able to choose to receive notifications in Odoo
or by email. The choice is no longer inbox or inbox + email, but inbox
or email. Choosing one option or the other one depends on the way the
user wants to work.
Technically the field is moved on the users model and selection keys
are renamed. Notification process is modified
* notified_partner_ids contains as before specified recipients as well
as followers matching the subtype
* customers and users working with emails are notified. During that
process customers notifications are marked as done to be able to
track the email state without having needaction. Users notifications
are currently deleted as we do not track their email state.
The removal of partner field implies changes in various addons that
define partner data with this field set in the values.
This commit cleans code to separate recipients computation in mail
message from notification mechanism in partner. There is no functional
change. Some variables have been renamed notably to know that
some of the record sets are sudoed during computation.
You may want to send emails related to a document not inheriting from
mail.thread. In that case we have to use the default computation of
reply_to and not call a method defined only if the model inherits
from mail.thread.
This commit introduces generic activities to use in your addons. Activities are
actions user have to take on a document like making a phonecall or organizing
a meeting. Activities come with the mail module as they are integrated in the
Chatter but are not bundled with mail.thread.
New models are
* mail.activity.type: used to categorize activities. Each type is a different
kind of activity e.g. call, mail, meeting. An activity can be generic i.e.
available for all models using activities; or specific to a model in which
case res_model_id field should be used.
* mail.activity: an actual activity to perform. Activities are linked to
documents using res_id and res_model_id fields. Activities have a deadline
that can be used in kanban view to display a status. Once done activities
are unlinked and a message is posted. This message has a new activity_type_id
field that indicates the activity linked to the message.
This commit introduces a mail.activity mixin to use in various addons that
enables the activities feature. It works like the mail.thread mixin. It defines
a activity_ids one2many field toward activities using res_id and res_model_id.
Various related / computed fields are also added to have a global status of
activities on documents.
Activities come with a new JS widget for the form view. It is integrated in the
Chatter widget although it is a separate widget. It displays activities linked
to the current record and allow to schedule, edit and mark done activities.
Use widget="mail_activity" on activity_ids field in form view to use it.
There is also a kanban widget defined. It defines a small widget to integrate
in kanban vignettes. It allow to manage activities directly from the kanban
view. Use widget="kanban_activity" on activitiy_ids field in kanban view to
use it.
Next commits will aim at integrating activities inside main Odoo addons.
Thanks to R&D India for their work and testing on this task. Thanks to belgian
Usabiliteam for reviewing and testing it. Thanks to @jem-odoo for the final
review. May his soul lie in peace with the trumpets of paradise.
When creating a mail.mail without giving a mail_message_id, a new mail.message
is created. It does then through _notify that notifies people of the message
creation. This leads to mail being sent two times, one when sending the
mail.mail, one when sending the notification.
This commits fixes that behavior. When creating directly a mail.mail without
giving a mail.message, call to _notify is bypassed. This way either an email
is created, either a message that has to be notified is created, but not both.
ir.needaction_mixin is not used anymore by the webclient.
From 9.0, the concept has changed: this feature is now
available in mail module, with the mail.thread mixin,
and message_neeadction field.
Remove all code handeling needaction bullet and
counter on ir.ui.menu, knowing that since 9.0
webclient does not display the counter anymore.
This code was, thus, useless and some RPC calls
were done for nothing, and adapt accounting
reconcialiation widget.
Indeed accessing a m2m applies record rules, meaning recipients are stripped for public and portal
users. However when displaying recipients of a chat it is necessary to know which are the
recipients.
Moreover a crash occurs when accessing notifications about email being sent or not. As messages
in the tree are now browsed as super user there is no access rights issues anymore.
Forum and blog are public models that could have a lot of followers. After
notifying followers of a new comment, discard the needaction information.
For those models email is considered as sufficient. This way we avoid storing
a lot of unnecessary entries in the m2m table between message and partner.
Using after commit event notifications emails are now send once the current
transaction is finished. This allows having issues with emails being sent
while the transaction failed sometimes after email sending, but still in the
same transaction.
A small hook is done to allow invitation emails to be sent directly as some
data related to mail.message is unlinked directly in the wizard.
This commit remove required alias on res.users model. It also removes the
inheritance of mail.alias.mixin. The field alias_id is kept and allow people
to use aliases on users if they want. However there is no default void alias
created for each user anymore.
Default from of mail.message does not use user alias anymore. Indeed this
creates issues with aliases not being correctly configured and can be
confusing compared to private channels. Using user aliases is therefore
now done manually instead of being a default behavior.
Currently it is impossible in Discuss to know whether an email has been sent
to a customer and whether it failed or bounced. A notified partner has an
entry in the needaction m2m table. In this commit we decorate this table to
add fields about the email notification: is an email sent, did it failed, did
it bounce.
This information is kept only for customers. Internal users does not use this
information. Moreover their notification is deleted once the message is read
in the Chatter. This avoids having a notification table that grows quickly.
Chatter now holds a new icon for email details. It allows to know on a thread
status of emails sent to customers.
mail.mail and mail.thread have methods to decode headers. This commit
move them in mail tools. It is indeed simplier to have all email tools
in the same file. Moreover they have been renamed to avoid confusion
with standard library methods: decode and decode_header already exist.
* decode in mail_message is now decode_smtp_header
* decode_header in mail_thread is now decode_message_header
A method to data from references is also moved into tools. A regex was
already defined in tools. Now the method using it is already put in tools.
Mailgateway will now simply call this method.
Now having
* sanitize: run the sanitizer to clean the html (removing javascripts,
unwanted tags, ...)
* sanitize_tags: only a subset of tags is allowed in html content.
Unwelcomed tags are remove dand their content stripped.
* sanitize_attributes: only a subset of attributes is allowed.
* sanitize_style: only a subset of style attributes is allowed. Style
attributes are parsed to keep only a white list.
* strip_style: all style is removed. It bypasses sanitize_style as there
is no need to sanitize something that is removed.
* strip_classes: remove class attributes
Fields parameters have also been updated to match the sanitize options. Html
fields by default are sanitized with sanitize_tags activated but without any
further options. All addons have been updated to match the new options
according to their previous behavior.
* mail_message.message_read() method is not used anymore since the chatter
refactoring in v9. message_format() is used instead. Tests for this method
are also removed, as they have no use anymore.
* mail_thread.message_set_read() is not used anymore. set_message_done is the
only method used by the new chatter as there is no read state anymore.
* removed an unused parameter in set_message_done, by the way
When posting a comment after an answer in the forum, a mail
was sent to each subscriber with 'Re: False' as title.
In fact the title has to be 'Re:' + the name of the parent
record of this message.
When a mail is sent from the post, a link to access the subject
of the forum must be included in the mail.
opw:679073
When tracking value is converted to be rendered as a message_post, we convert
the date/datetime with the current local from momentjs.
Related to #12327
Courtesy of @aab-odoo for help and review.
Avoid raising an access denied error for messages that
the user has indeed be notified about.
The issue arose when a message posted on a document inaccessible
to the user was notified to one of the channels the user
is subscribed to.
The access control logic on messages relies on 2 heuristics
to grant read access to a message:
a. either the user was notified about the messages, by being
a follower of the document, or a subscriber of a channel
following the document (in that case the user can see the
message but not the document)
b. or the user has read access to the document on which the
message is posted (in that case the user can see both
the message and the document)
Case `a.` sometimes fail to match when a message got notified
to several channels including one the user was not subscribed
to. Depending on the order of the returned rows in the SQL
query, the "foreign" channels could shadow the channels of
the user, making `a.` a non-match.
If case `b.` did not match either, the user would have the
`read` access denied, even though the message was visible by
the `search()` method.
The fix explicitly makes case `a.` match if the user was
notified in *at least* one channel.
This was not done through a change of the SQL query ORDER,
for readability reasons.
By default, users are supposed to be able to write messages
in threads only if they have the write access on the record.
This behavior is the behavior defined in Odoo 8.0.
This behavior can be changed by defining
`_mail_post_access` on the model,
to allow the creation of new messages
if the user has only the read access, for instance.
This is the case on `project.issue`, for instance.
Since 9.0, @ revision 88b8cd0587,
this behavior was broken: Any users having the read
access on the record was allowed to write messages in the thread,
while this should not be the case, except if
`_mail_post_access = 'read'`
has been defined on the model.
This is because the SQL query which is performed in order
to know the thread messages the user has been notified of
was expected to return only the ids of the notified message,
while it actually always returned all the message ids of the thread,
because of the LEFT JOINS, e.g.
```
LEFT JOIN "mail_message_res_partner_rel" partner_rel
ON partner_rel.mail_message_id = m.id AND partner_rel.res_partner_id = (%%s)
```
Instead of just checking the ids of the messages returned by this
query, it must check that one of the two columns
`partner_rel.res_partner_id` or `channel_partner.partner_id`
is filled, meaning the partner has been notified of the message or
is a member of the channel the message has been posted to.
opw-668589
Christophe Simonis