[IMP] mail: prepare new SMS model by updating mail.notification

This commit prepares SMS refactoring by updating some mail models. Purpose
is to be able to store SMS notification information inside existing mail
flow and models.

Main changes

  * mail.notification: define a notification_type field to store the medium
    used to notify people. In mail two ways exist: inbox and email. It will
    ease introduction of SMS notification mechanism. This field replaces the
    is_email boolean field;
  * mail.notification: make res_partner_id field not required. This means
    notifications could be linked to something else than a partner. An SMS
    for example. For Inbox and email notifications partner is still required
    and a constraint is added accordingly;
  * mail.thread: let notification methods handle the creation and update of
    their notification instead of creating them in _notify_thread and tweaking
    them in sub notification methods;
  * mail.thread: clearly move inbox-style notification in its own method like
    notify by email;

Some lighter code changes

  * propagate message_type to notification recipient computation. It will
    allow for example to be more precise when computing a notification type
    depending on the message_type. For example, send a notification by SMS
    when the message_type is SMS;
  * ease inheritance of ``_notify_thread`` by returning computed recipients
    data. It will allow to work on it without having to re-compute it;
  * propagate kwargs from message_post and message_notify to notify methods.
    This allow to avoid depending on context and set explicit parameters.
    Drawback is that message_post and notify must separate kwargs used to
    create a message and those that are propagated to notification methods;
  * update various notification check to ensure they work on email
    notifications, notably the resend and cancel wizards;

One side effect of this commit is that notifications are created by the
relevant notification method. Previously all notifications were created
by writing on needaction_partner_ids fields then updated according to the
notification process. Notably there could be too much notification created
when sending emails due to _notify_customize_recipients not being correctly
synchronized with notification. This issue is now solved as only really
sent emails create notifications.

Migration tips

  * notification_type: notification.is_email and 'email' else 'inbox';
  * remove is_email;

Related to task 1922163
Linked to PR #33510

1 files changed, 4 insertions, 5 deletions

diff --git a/addons/website_blog/models/website_blog.py b/addons/website_blog/models/website_blog.py
index 6ddb0cb06a6..da71c1b3194 100644
--- a/addons/website_blog/models/website_blog.py
+++ b/addons/website_blog/models/website_blog.py
@@ -259,14 +259,13 @@ class BlogPost(models.Model):
         return groups
 
     @api.multi
-    def _notify_customize_recipients(self, message, msg_vals):
+    def _notify_record_by_inbox(self, message, recipients_data, msg_vals=False, **kwargs):
         """ Override to avoid keeping all notified recipients of a comment.
         We avoid tracking needaction on post comments. Only emails should be
         sufficient. """
-        msg_type = msg_vals.get('message_type') or message.message_type
-        if msg_type == 'comment':
-            return {'needaction_partner_ids': []}
-        return super(BlogPost, self)._notify_customize_recipients(message, msg_vals)
+        if msg_vals.get('message_type', message.message_type) == 'comment':
+            return
+        return super(BlogPost, self)._notify_record_by_inbox(message, recipients_data, msg_vals=msg_vals, **kwargs)
 
     def _default_website_meta(self):
         res = super(BlogPost, self)._default_website_meta()