Only messages as comments and email template should keep a white backround since they are not internal.
It is also enough to display fields that changed on subtypes (update message) since emails will be reworked soon and more information will be given there. The support of 'always' track can be removed. (is now considered as a simple tracked field)
The use of self.env.ref('mail.mt_comment').id add some query and the performance tests needs to be update since message_format is called by notify_by_chat. This code will be refactor later
Purpose of this commit is to perform a light cleaning of the email
notification process. It renames method by prefixing them by _notify
in order to easily spot them. It also makes them private because they
should not be called outside of other methods. Indeed those methods
are technical and do not provide useful information to external
people.
Future commits will probably improve the notification process in order
to clean it and try to reduce its query count.
This commit perform the following renaming
* message_get_email_values -> _notify_specific_email_values
* message_get_recipient_values -> _notify_email_recipients
* _message_notification_recipients -> _notify_classify_recipients
* message_get_reply_to -> _notify_get_reply_to
Purpose of this commit is to add a new parameter to message post that
is the layout used when sending notification emails. It will soon
replace the context use of custom_layout in some case. It will also
allow to control a bit the notification process from the message_post
API in more or less planned future mail updates.
This commit also slightly changes the way notification process handles
deleted or unknown rendering templates. Before this commit any missing
custom template was replaced by the base template. A missing base
template was leading to a crash. Now it simply logs a warning and avoid
crashing.
Before this commit, users had only access to messages if they were
recipients. However, you can still be notified for messages your are not
a recipient; leaving you with notifications (needaction) on unreachable
message.
The "Mark all read" button either set all messages as read, or if a
domain is given, filter messages on it.
But this filtering is also dependent on not doing sudo so odd
notification to which we would somehow not have any access would never
disappear in the unread number.
Adding a sudo is risky, so this changeset just modify the test on domain
since in most instance the domain is just an empty list (so: []).
The added test before this change would fail at the last assert ("mark
all read should conclude all needactions even inacessible ones").
opw-805185
closes#22277
Purpose
* move notify in message_post instead of always doing it at message
creation
Specifications
* message create should only create a message
* message post should be in charge of calling the notification process
When
- a user A had set 'notifications handled by Odoo'
- a user B sent a @userA message
Before this commit, the user wasn't notified in the inbox needaction
After this commit, he is
OPW 801315
Posting a message on a custom model (i.e. created with Studio) crashed.
If it's a custom model, its `_original_module` attribute is not correctly set so
trying to retrieve the icon based on this attribute does not work.
Now that we're closer to switching to P3 for good, these helpers have
outlived their usefulness, and mostly add noise.
All remaining dict.iter*() or dict.view*() must be converted to the
normal keys(), values() or items() calls.
Whenever the result is likely to be used for more than the scope of a
loop, or when the dict needs to be modified during iteration, the calls
must be wrapped in a ``list()``, to protect the new P3 semantics.
Those cases are very exceptional.
Also removed some dead code or improved the API to remove unnecessary
conversions.
Before this fix, the base64 image are remove and never send. The images
were in the body increasing the size of the database unnecessarily
(cfr some odoo users with the chatter)
NB: According to the prophecy Khoi will come and dominate the world,
ask him anything
Replace `model.search([('id', 'in', ids)])` by `model.browse(ids)`, which is
safe because `ids` come from reading a many2one field. The performance impact
is negligible.
This commit improves the use of activities through various applications
by adding a counter of activities displaying next activities grouped by
application. For each application activities are divided into late, today
and future activities in order to achieve a better management.
This commit also merges Inbox and Messaging icons in topbar to keep only
one displaying All / Chat / Channels messages.
In Python 3:
* various builtins and dict methods were changed to return
view/iterable objects rather than lists
* and the separate Python 2 view/iterable builtins and methods were
removed altogether
This is problematic when using these items as list (which the happens
repeatedly in Odoo), but more viciously when iterating *multiple times*
over them (which also happens, which I've messed up multiple times while
writing this, and which is a pain to debug even when you've just created
the issue).
Convert all code using these to semantics-matching cross-version
helper functions to get the LCD behaviour between P2 and P3, and
forbid the builtins via lint.
issue #8530
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.
Xavier-Do