Student projects/Further messaging improvements

Jump to: navigation, search

The messaging system in 2.0 has been revamped significantly. It is now event-driven, and allows users to control exactly what messages they receive and how.

How to enable it

Admin > Optional subsystems > Enable messaging system = Yes

How to configure it

Visit your own profile page (you need moodle/user:editownmessageprofile permission). Note that the types of messages listed in the "Configure destinations for incoming messages" box is determined by the contents of the message_providers table.


How it works

Providers (input)

We have Events called "message_send" that look like this:

$eventdata = new object();
$eventdata->component         = 'mod_forum';    // the component sending the message. Along with name this must exist in the table message_providers
$eventdata->name              = 'posts';        // type of message from that module (as module defines it). Along with component this must exist in the table message_providers
$eventdata->userfrom          = $userfrom;      // user object
$eventdata->userto            = $userto;        // user object
$eventdata->subject           = $postsubject;   // very short one-line subject
$eventdata->fullmessage       = $posttext;      // raw text
$eventdata->fullmessageformat = FORMAT_PLAIN;   // text format
$eventdata->fullmessagehtml   = $posthtml;      // html rendered version
$eventdata->smallmessage      = '';             // useful for plugins like sms or twitter
events_trigger('message_send', $eventdata);

The name of each provider is a string with a name like messageprovider:$name from the component lang file (in this case, forum.php is derived automatically from mod/forum):

$string['messageprovider:posts'] = 'Subscribed forum posts';
$string['messageprovider:digests'] = 'Subscribed forum digests';

More providers can be added throughout Moodle as necessary, it's quite easy. See the Events API for info.

Processors (output)

In /message/output there are full Moodle plugins for each type of output.

Currently we have support for email, jabber and web-based popups. Could add twitter and SMS quite easily.

Each plugin simply extends a class called "message_output" in /message/output/lib.php with methods such as:

function send_message($message) {
   // Given a message object and user info, this actually sends it.
function config_form($preferences) {
   // This defines the little form fragment on the config page
function process_form($form, &$preferences) {
   // This processes the data from the config form fragment
function load_data(&$preferences, $userid) {
   // This loads up prefs for this plugin

It should also provide a messageprocessor_xxxxx.php language file (where xxxxx is the name) and inside is an xxxxx string with the name of the processor, like this:

$string['jabber'] = 'Jabber message';

Finally, there should be a lib.php file containing an install routine to install itself as a message processor:

function jabber_install(){
    global $DB;
    $result = true;
    $provider = new object();
    $provider->name  = 'jabber';
    if (!$DB->insert_record('message_processors', $provider)) {
        $result = false;
    return $result;

And a version.php file:

$plugin->version  = 2008090900;
$plugin->requires = 2008091500;

See also