The message and activity features

The message and activity features

Odoo has available global messaging and activity planning features, provided by the Discuss application, with technical name mail.

The mail module provides the mail.thread abstract class that makes it simple to add the messaging features to any model, and the mail.activity.mixin that adds planned activity features. This was done in Chapter 4, Extending Modules, to explain how to inherit features from mixin abstract classes.

To add these features, we need to add the mail dependency to the add-on module, library_checkout, and then have the library checkout model class inherit from the abstract classes providing the following features.

Edit the 'depends' key in the library_checkout/__manifest__.py  file, to add the mail module, shown as follows:

  'depends': ['library_member', 'mail'],

And edit the library_checkout/models/library_checkout.py file to inherit from the mixin abstract models, shown as follows:

class Checkout(models.Model): 
    _name = 'library.checkout'
    _description = 'Checkout Request'
    _inherit = [''mail.thread', 'mail.activity']

After this, among other things, our model will have three new fields available. For each record (sometimes also called a document), we have the following:

• mail_follower_ids stores the followers and corresponding notification preferences
• mail_message_ids lists all of the related messages.activity_ids with all of the related planned activities

The followers can be either partners or channels. A partner represents a specific person or organization. A channel is not a particular person, and instead represents a subscription list.

Each follower also has a list of message types that they are subscribed to. Only the selected message types will generate notifications for them.

Message subtypes

Some types of messages are called subtypes. They are stored in the mail.message.subtype model and are accessible in the Technical | Email | Subtypes menu.

By default, we have the following three message subtypes available:

• Discussions, with mail.mt_comment XMLID, used for the messages created with the Send message link. It is intended to send a notification.
• Activities, with mail.mt_activities XMLID, used for the messages created with the Schedule activity link. It is not intended to send a notification.
• Note, with mail.mt_note XMLID, used for the messages created with the Log note link. It is not intended to send a notification.

Subtypes have the default notification settings described previously, but users are able to change them for specific documents, for example, to mute a discussion they aren't interested in.

Other than the built-in subtypes, we can also add our own subtypes to customize the notifications for our applications. Subtypes can be generic or intended for a particular model. For the latter case, we should fill in the subtype's res_model field with the name of the model it should apply to.

Posting messages

Our business logic can make use of this messaging system to send notifications to users. To post a message, we use the message_post() method. The following is an example of this:

self.message_post('Hello!')

This adds a simple text message, but sends no notification to the followers. That is because, by default, the mail.mt_note subtype is used for the posted messages. But we can have the message posted with the particular subtype we want. To add a message and have it send notifications to the followers, we should use the mt_commentsubtype. Another optional attribute is the message'ssubject. Here, is an example using both options:

self.message_post('Hello again!', subject='Hello', subtype='mail.mt_comment')

The message body is HTML, so we can include markup for text effects, such as <b> for bold text or <i> for italics. 

Note

The message body will be sanitized for security reasons, so some particular HTML elements may not make it to the final message.

Adding followers

Also interesting from a business logic viewpoint is the ability to automatically add followers to a document, so that they can then get the corresponding notifications. For this, we have several methods available to add followers, listed as follows:

• message_subscribe(partner_ids=<list of int IDs>) adds partners
• message_subscribe(channel_ids=<list of int IDs>) adds channels
• message_subscribe_users(user_ids=<list of int IDs>) adds users

The default subtypes will be applied to each subscriber. To force subscribing a specific list of subtypes, add an additional attribute  subtype_ids=<list of int IDs>, listing the specific subtypes to enable for the subscription.

---