Note: You are currently viewing documentation for Moodle 2.4. Up-to-date documentation for the latest stable version of Moodle may be available here: Messaging 2.0.

Development:Messaging 2.0: Difference between revisions

From MoodleDocs
 
(20 intermediate revisions by 4 users not shown)
Line 1: Line 1:
<p class="note">'''Note''': This page outlines ideas for further messaging improvements. It's a ''specification under construction''! If you have any comments or suggestions, please add them to the [[Development talk:Messaging 2.0|page comments]].''</p>
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.


==Revise 2007 code==


First steps are to review the current code:
==How to enable it==
# [http://cvs.moodle.org/contrib/patches/messaging_v2/ 2007 code]]
# Make code conform to [[Coding| Code guidelines]]
# Add phpdocs 
# lib/messagelib.php
# Review from mentor and other programmers
# Check into HEAD
# Continue polishing as necessary


Admin > Optional subsystems > Enable messaging system = Yes


==Extend basic messaging system==


# Store content formats for each message and use these when routing messages.  eg HTML messages from forums should be converted into basic text, etc  Sometimes certain message types won't be possible to route to certain output plugins - the GUI should indicate this clearly.
==How to configure it==
# Test everything very well.


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.


==Enhance the messaging popup GUI==
[[Image:Messagingconfig.png]]


# Examine [http://tracker.moodle.org/browse/MDL/component/10084 the requests in the tracker], edit/prioritise/improve them
==How it works==
# [http://moodle.org/mod/forum/view.php?id=2697 Publicise the project in the forums], ask community to file issues and/or vote on them
 
# Tackle the [http://tracker.moodle.org/browse/MDL/component/10084?selected=com.atlassian.jira.plugin.system.project:component-popularissues-panel most requested items] first
===Providers (input)===
We have [[Development:Events|Events]] called "message_send" that look like this:
 
<code php>
$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);
</code>
 
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):
 
<code php>
$string['messageprovider:posts'] = 'Subscribed forum posts';
$string['messageprovider:digests'] = 'Subscribed forum digests';
</code>
 
More providers can be added throughout Moodle as necessary, it's quite easy.  See the [[Development:Events|Events API]] for info.
 
===Processors (output)===
 
In [http://cvs.moodle.org/moodle/message/output /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 [http://cvs.moodle.org/moodle/message/output/lib.php /message/output/lib.php] with methods such as:
 
<code php>
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
}
</code>
 
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:
 
<code php>
$string['jabber'] = 'Jabber message';
</code>
 
Finally, there should be a '''lib.php file''' containing an install routine to install itself as a message processor:
 
<code php>
function jabber_install(){
    global $DB;
 
    $result = true;
 
    $provider = new object();
    $provider->name  = 'jabber';
    if (!$DB->insert_record('message_processors', $provider)) {
        $result = false;
    }
    return $result;
}
</code>
 
And a '''version.php''' file:
<code php>
$plugin->version  = 2008090900;
$plugin->requires = 2008091500;
</code>


==See also==
==See also==
Line 29: Line 101:
* [[GSOC/2008]]
* [[GSOC/2008]]
* [[Student projects/Messaging improvements|Messaging improvements]], a GSOC 2007 project
* [[Student projects/Messaging improvements|Messaging improvements]], a GSOC 2007 project
* [[Development:Events|Events API]]
* MDL-10107
* MDL-10107


[[Category:Project]]
[[Category:Messaging]]
[[Category:Developer]]

Latest revision as of 06:59, 9 November 2010

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