MoodleDocs - User contributions [en]

Development:Messaging

2008-09-25T17:42:34Z

Lfrodrigues: /* Sending a Message */

The Messageing API is a new core system in Moodle to allow communication of messages to users. It's based on the events system, so a module will trigger an event with the attached message data and the message output processor will try to deliver the message to the correct place.

==Overview==

===Setting up a provider===
* db/messages.php (list the types of providers)
* /lang/XX/messages/providercomponent_providername.html (documentation)
...

===Setting up a processor===

===Sending a Message===

Whenever you need to send a message, it should “tell” the system about it. So, using the message as an example, we first define an object as follows:

$eventdata = new object();
$eventdata->component = "message";
$eventdata->name = "instantmessage";
$eventdata->userfrom = $userfrom;
$eventdata->userto = $userto;
$eventdata->subject = "IM";
$eventdata->fullmessage = $message;
$eventdata->fullmessageformat = FORMAT_PLAIN;
$eventdata->fullmessagehtml = "";
$eventdata->smallmessage = "";

Then we post the object as an event and forget about it:

events_trigger('message_send', $eventdata);

Development:Messaging

2008-09-25T17:41:57Z

Lfrodrigues:

The Messageing API is a new core system in Moodle to allow communication of messages to users. It's based on the events system, so a module will trigger an event with the attached message data and the message output processor will try to deliver the message to the correct place.

==Overview==

===Setting up a provider===
* db/messages.php (list the types of providers)
* /lang/XX/messages/providercomponent_providername.html (documentation)
...

===Setting up a processor===

===Sending a Message===

Whenever you need to send a message, it should “tell” the system about it. So, using the message as an example, we first define an object as follows:

$eventdata = new object();
$eventdata->component = 'message';
$eventdata->name = 'instantmessage';
$eventdata->userfrom = $userfrom;
$eventdata->userto = $userto;
$eventdata->subject = "IM";
$eventdata->fullmessage = $message;
$eventdata->fullmessageformat = FORMAT_PLAIN;
$eventdata->fullmessagehtml = '';
$eventdata->smallmessage = '';

Then we post the object as an event and forget about it:

events_trigger('message_send', $eventdata);

Development:Messaging

2008-09-25T16:31:02Z

Lfrodrigues:

Development:Messaging

2008-09-25T13:30:32Z

Lfrodrigues: New page: The Messageing API is a new core system in Moodle to allow communication of messages to users. It's based on the events system, so a module will trigger an event with the attached message ...

Student projects/Messaging improvements

2007-08-01T18:26:36Z

Lfrodrigues: /* Changes */

'''Programmer:''' Luis Filipe Romão Rodrigues

The status of this project is being tracked here: [http://tracker.moodle.org/browse/MDL-10107 MDL-10107]

=Summary=
The Moodle messaging system in Moodle is a bit clunky and could use improvements to make it slicker and more efficient as a tool for messaging people within the Moodle environment.

Functionality improvements:
* Add a messaging API class to the core of Moodle which all modules will start using for sending messages (currently they all format their own emails).
* Add output plugins to messaging so that users can choose exactly how to route their messages, especially when they aren't online at the time. Initially the two plugins would be "browser" and "email", but later there could be a jabber plugin, an IRC plugin etc)

Gui improvements:
* Improve the main message GUI using AJAX (Moodle includes the YUI library so you'd need to use that)
* Improve the messaging window to allow chats among three or more other people at once.
* GUI for the output plugins to allow users to set rules about each plugin independently, and also to select from incoming messages by type, by user or by moodle module.
* Improve the methods to search messages and find discussions from the past.
* Improve administrator auditing of message logs, including filtering etc.

=Project Information=

==Mockups==

===User Profile mockup===
[[Image:Lfrodrigues-_messaging_config.jpg]]

===Improved search interface===

===Improved history view===

===Administrator reports===

==System Overview==
[[Image:lfrodrigues_system_overview.png]]

==Possible implementarions==
I see two ways of implementing this. My main problem at this stage is that I really don't know if there are real peformance gains with a new system.
===Using Events===
New messages are posted as events. The core messaging code has a handler to grab them and to choose how
to process them.

Martin told me that if the system gets too "popular these messages become COULD be a little heavy on the system".

This approach seams the easiest a better because I would reuse a lot of code (good software practice) but don't know about the performance escalates

===Develop a new class===
I could also implement a completely separate and probably much simpler system where all modules just call a function to add a new message to a queue. The system would the process the messages and choose how to process them.

(I really don't think this can be any more efficient than events, really, and the advantages of using events are too great. If events system doesn't cut it then we can optimise that. -- [[User:Martin Dougiamas|Martin Dougiamas]] 08:31, 15 May 2007 (CDT))

==Plugins==

Plugins should be located under the "message" directory eg:

/message/output/browser (special case, as hooks need to also be included elsewhere as in 1.8)
/message/output/email
/message/output/jabber

The plugins should be full Moodle citizens with db directories, version.php files etc.

==Message Sources==

Somehow all the modules need to register themselves as a *message source* so that the messaging GUI can easily list all the sources.

We could develop something new, or we could extend the [[Development:Events|Events API]] so that modules can optionally use the events.php mechanism to register themselves as known "triggers" (sources) of certain events. I'm inclining strongly toward this latter method.

A catch-all category of "Other messages" would be applied to any unknown incoming messages for which no settings are defined.

Modules will triger an "Register Message Source" event in widget_add_instance() and a "Remove Message Source" in widget_delete_instance() -- Is this correct?

==Changes==

moodlelib.php still needs to be adapted to the new system since it still uses emails
===Files that need changing===

With modules/files need to be adapted to the new system?
* the ones with send email
* ??

===Modules/Files with send emails===

This modules/files send email using email_to_user, is there any other?

Modules:

* journal,
* forum,
* lesson,
* workshop,
* assignment
* exercise
* quiz

Other files that need changing:
*./admin/handlevirus.php
*./admin/process_email.php
*./backup/backup_scheduled.php
*./course/pending.php
*./enrol/authorize/enrol.php
*./enrol/authorize/localfuncs.php
*./enrol/authorize/uploadcsv.php
*./enrol/flatfile/enrol.php
*./enrol/imsenterprise/enrol.php
*./enrol/manual/enrol.php
*./enrol/paypal/ipn.php
*./error/index.php
*./lib/moodlelib.php
*./lib/uploadlib.php
*./message/lib.php
*./mod/assignment/lib.php
*./mod/exercise/lib.php
*./mod/forum/lib.php
*./mod/journal/lib.php
*./mod/lesson/essay.php
*./mod/workshop/lib.php

==Other ideas from the community==

*The ability to black-list individual users or groups/groupings site-wide.
*The ability to grey-list individual users or groups/groupings site-wide (only able to IM specified roles at site or course level).
*The ability to add an attachment to IMs (with a maximum size selected at the site level). I would think that this ability could be limited by role, and turned on or off at the site level.
* As a teacher, you want to send different messages at the same time to many students. There should be an option, where teacher selects many individual student or a group of students or the entire class, types in the individual messages next to the student name, and does a one click send to all
* Finding history of messages is very difficult. It needs more options, you should be able to select a period between two dates and find all sent / received messages within those dates.
* The "pop up" window for message is clumsy, and the css is not properly defined
* The message block can presently be used for live chat also, if both participants are online. However, it is not "designed" for the same, more features could be added, allowing one to see who all students of the community are online, and an option to start chat with them.
* Ideally, the live chat element would allow some way to elegantly hold 2 or more separate conversations at once. Currently, this involves having multiple messaging windows open at once and trying to work out who has just said something when it 'dings' in the background is difficult. A tabbed interface like the accordion theme/google chat would be ideal.

==Important Forum Posts==
http://moodle.org/mod/forum/discuss.php?d=63401
http://moodle.org/mod/forum/discuss.php?d=38838

Back: [[Student_projects]]

Student projects/Messaging improvements

2007-08-01T18:20:32Z

Lfrodrigues: /* Modules/Files with send emails */

'''Programmer:''' Luis Filipe Romão Rodrigues

The status of this project is being tracked here: [http://tracker.moodle.org/browse/MDL-10107 MDL-10107]

=Summary=
The Moodle messaging system in Moodle is a bit clunky and could use improvements to make it slicker and more efficient as a tool for messaging people within the Moodle environment.

Functionality improvements:
* Add a messaging API class to the core of Moodle which all modules will start using for sending messages (currently they all format their own emails).
* Add output plugins to messaging so that users can choose exactly how to route their messages, especially when they aren't online at the time. Initially the two plugins would be "browser" and "email", but later there could be a jabber plugin, an IRC plugin etc)

Gui improvements:
* Improve the main message GUI using AJAX (Moodle includes the YUI library so you'd need to use that)
* Improve the messaging window to allow chats among three or more other people at once.
* GUI for the output plugins to allow users to set rules about each plugin independently, and also to select from incoming messages by type, by user or by moodle module.
* Improve the methods to search messages and find discussions from the past.
* Improve administrator auditing of message logs, including filtering etc.

=Project Information=

==Mockups==

===User Profile mockup===
[[Image:Lfrodrigues-_messaging_config.jpg]]

===Improved search interface===

===Improved history view===

===Administrator reports===

==System Overview==
[[Image:lfrodrigues_system_overview.png]]

==Possible implementarions==
I see two ways of implementing this. My main problem at this stage is that I really don't know if there are real peformance gains with a new system.
===Using Events===
New messages are posted as events. The core messaging code has a handler to grab them and to choose how
to process them.

Martin told me that if the system gets too "popular these messages become COULD be a little heavy on the system".

This approach seams the easiest a better because I would reuse a lot of code (good software practice) but don't know about the performance escalates

===Develop a new class===
I could also implement a completely separate and probably much simpler system where all modules just call a function to add a new message to a queue. The system would the process the messages and choose how to process them.

(I really don't think this can be any more efficient than events, really, and the advantages of using events are too great. If events system doesn't cut it then we can optimise that. -- [[User:Martin Dougiamas|Martin Dougiamas]] 08:31, 15 May 2007 (CDT))

==Plugins==

Plugins should be located under the "message" directory eg:

/message/output/browser (special case, as hooks need to also be included elsewhere as in 1.8)
/message/output/email
/message/output/jabber

The plugins should be full Moodle citizens with db directories, version.php files etc.

==Message Sources==

Somehow all the modules need to register themselves as a *message source* so that the messaging GUI can easily list all the sources.

We could develop something new, or we could extend the [[Development:Events|Events API]] so that modules can optionally use the events.php mechanism to register themselves as known "triggers" (sources) of certain events. I'm inclining strongly toward this latter method.

A catch-all category of "Other messages" would be applied to any unknown incoming messages for which no settings are defined.

Modules will triger an "Register Message Source" event in widget_add_instance() and a "Remove Message Source" in widget_delete_instance() -- Is this correct?

==Changes==
===Files that need changing===

With modules/files need to be adapted to the new system?
* the ones with send email
* ??

===Modules/Files with send emails===

This modules/files send email using email_to_user, is there any other?

Modules:

* journal,
* forum,
* lesson,
* workshop,
* assignment
* exercise
* quiz

Other files that need changing:
*./admin/handlevirus.php
*./admin/process_email.php
*./backup/backup_scheduled.php
*./course/pending.php
*./enrol/authorize/enrol.php
*./enrol/authorize/localfuncs.php
*./enrol/authorize/uploadcsv.php
*./enrol/flatfile/enrol.php
*./enrol/imsenterprise/enrol.php
*./enrol/manual/enrol.php
*./enrol/paypal/ipn.php
*./error/index.php
*./lib/moodlelib.php
*./lib/uploadlib.php
*./message/lib.php
*./mod/assignment/lib.php
*./mod/exercise/lib.php
*./mod/forum/lib.php
*./mod/journal/lib.php
*./mod/lesson/essay.php
*./mod/workshop/lib.php

==Other ideas from the community==

*The ability to black-list individual users or groups/groupings site-wide.
*The ability to grey-list individual users or groups/groupings site-wide (only able to IM specified roles at site or course level).
*The ability to add an attachment to IMs (with a maximum size selected at the site level). I would think that this ability could be limited by role, and turned on or off at the site level.
* As a teacher, you want to send different messages at the same time to many students. There should be an option, where teacher selects many individual student or a group of students or the entire class, types in the individual messages next to the student name, and does a one click send to all
* Finding history of messages is very difficult. It needs more options, you should be able to select a period between two dates and find all sent / received messages within those dates.
* The "pop up" window for message is clumsy, and the css is not properly defined
* The message block can presently be used for live chat also, if both participants are online. However, it is not "designed" for the same, more features could be added, allowing one to see who all students of the community are online, and an option to start chat with them.
* Ideally, the live chat element would allow some way to elegantly hold 2 or more separate conversations at once. Currently, this involves having multiple messaging windows open at once and trying to work out who has just said something when it 'dings' in the background is difficult. A tabbed interface like the accordion theme/google chat would be ideal.

==Important Forum Posts==
http://moodle.org/mod/forum/discuss.php?d=63401
http://moodle.org/mod/forum/discuss.php?d=38838

Back: [[Student_projects]]

Student projects/Messaging improvements

2007-06-27T10:48:05Z

Lfrodrigues: /* Modules/Files with send emails */

'''Programmer:''' Luis Filipe Romão Rodrigues

The status of this project is being tracked here: [http://tracker.moodle.org/browse/MDL-10107 MDL-10107]

=Summary=
The Moodle messaging system in Moodle is a bit clunky and could use improvements to make it slicker and more efficient as a tool for messaging people within the Moodle environment.

Functionality improvements:
* Add a messaging API class to the core of Moodle which all modules will start using for sending messages (currently they all format their own emails).
* Add output plugins to messaging so that users can choose exactly how to route their messages, especially when they aren't online at the time. Initially the two plugins would be "browser" and "email", but later there could be a jabber plugin, an IRC plugin etc)

Gui improvements:
* Improve the main message GUI using AJAX (Moodle includes the YUI library so you'd need to use that)
* Improve the messaging window to allow chats among three or more other people at once.
* GUI for the output plugins to allow users to set rules about each plugin independently, and also to select from incoming messages by type, by user or by moodle module.
* Improve the methods to search messages and find discussions from the past.
* Improve administrator auditing of message logs, including filtering etc.

=Project Information=

==Mockups==

===User Profile mockup===
[[Image:Lfrodrigues-_messaging_config.jpg]]

===Improved search interface===

===Improved history view===

===Administrator reports===

==System Overview==
[[Image:lfrodrigues_system_overview.png]]

==Possible implementarions==
I see two ways of implementing this. My main problem at this stage is that I really don't know if there are real peformance gains with a new system.
===Using Events===
New messages are posted as events. The core messaging code has a handler to grab them and to choose how
to process them.

Martin told me that if the system gets too "popular these messages become COULD be a little heavy on the system".

This approach seams the easiest a better because I would reuse a lot of code (good software practice) but don't know about the performance escalates

===Develop a new class===
I could also implement a completely separate and probably much simpler system where all modules just call a function to add a new message to a queue. The system would the process the messages and choose how to process them.

(I really don't think this can be any more efficient than events, really, and the advantages of using events are too great. If events system doesn't cut it then we can optimise that. -- [[User:Martin Dougiamas|Martin Dougiamas]] 08:31, 15 May 2007 (CDT))

==Plugins==

Plugins should be located under the "message" directory eg:

/message/output/browser (special case, as hooks need to also be included elsewhere as in 1.8)
/message/output/email
/message/output/jabber

The plugins should be full Moodle citizens with db directories, version.php files etc.

==Message Sources==

Somehow all the modules need to register themselves as a *message source* so that the messaging GUI can easily list all the sources.

We could develop something new, or we could extend the [[Development:Events|Events API]] so that modules can optionally use the events.php mechanism to register themselves as known "triggers" (sources) of certain events. I'm inclining strongly toward this latter method.

A catch-all category of "Other messages" would be applied to any unknown incoming messages for which no settings are defined.

Modules will triger an "Register Message Source" event in widget_add_instance() and a "Remove Message Source" in widget_delete_instance() -- Is this correct?

==Changes==
===Files that need changing===

With modules/files need to be adapted to the new system?
* the ones with send email
* ??

===Modules/Files with send emails===

This modules/files send email using email_to_user, is there any other?

Modules:

* journal,
* forum,
* lesson,
* workshop,
* assignment
* exercise

Other files that need changing:
*./admin/handlevirus.php
*./admin/process_email.php
*./backup/backup_scheduled.php
*./course/pending.php
*./enrol/authorize/enrol.php
*./enrol/authorize/localfuncs.php
*./enrol/authorize/uploadcsv.php
*./enrol/flatfile/enrol.php
*./enrol/imsenterprise/enrol.php
*./enrol/manual/enrol.php
*./enrol/paypal/ipn.php
*./error/index.php
*./lib/moodlelib.php
*./lib/uploadlib.php
*./message/lib.php
*./mod/assignment/lib.php
*./mod/exercise/lib.php
*./mod/forum/lib.php
*./mod/journal/lib.php
*./mod/lesson/essay.php
*./mod/workshop/lib.php

==Other ideas from the community==

*The ability to black-list individual users or groups/groupings site-wide.
*The ability to grey-list individual users or groups/groupings site-wide (only able to IM specified roles at site or course level).
*The ability to add an attachment to IMs (with a maximum size selected at the site level). I would think that this ability could be limited by role, and turned on or off at the site level.
* As a teacher, you want to send different messages at the same time to many students. There should be an option, where teacher selects many individual student or a group of students or the entire class, types in the individual messages next to the student name, and does a one click send to all
* Finding history of messages is very difficult. It needs more options, you should be able to select a period between two dates and find all sent / received messages within those dates.
* The "pop up" window for message is clumsy, and the css is not properly defined
* The message block can presently be used for live chat also, if both participants are online. However, it is not "designed" for the same, more features could be added, allowing one to see who all students of the community are online, and an option to start chat with them.
* Ideally, the live chat element would allow some way to elegantly hold 2 or more separate conversations at once. Currently, this involves having multiple messaging windows open at once and trying to work out who has just said something when it 'dings' in the background is difficult. A tabbed interface like the accordion theme/google chat would be ideal.

==Important Forum Posts==
http://moodle.org/mod/forum/discuss.php?d=63401
http://moodle.org/mod/forum/discuss.php?d=38838

Back: [[Student_projects]]

Student projects/Messaging improvements

2007-06-19T13:35:51Z

Lfrodrigues: /* Modules/Files with send emails */

'''Programmer:''' Luis Filipe Romão Rodrigues

The status of this project is being tracked here: [http://tracker.moodle.org/browse/MDL-10107 MDL-10107]

=Summary=
The Moodle messaging system in Moodle is a bit clunky and could use improvements to make it slicker and more efficient as a tool for messaging people within the Moodle environment.

Functionality improvements:
* Add a messaging API class to the core of Moodle which all modules will start using for sending messages (currently they all format their own emails).
* Add output plugins to messaging so that users can choose exactly how to route their messages, especially when they aren't online at the time. Initially the two plugins would be "browser" and "email", but later there could be a jabber plugin, an IRC plugin etc)

Gui improvements:
* Improve the main message GUI using AJAX (Moodle includes the YUI library so you'd need to use that)
* Improve the messaging window to allow chats among three or more other people at once.
* GUI for the output plugins to allow users to set rules about each plugin independently, and also to select from incoming messages by type, by user or by moodle module.
* Improve the methods to search messages and find discussions from the past.
* Improve administrator auditing of message logs, including filtering etc.

=Project Information=

==Mockups==

===User Profile mockup===
[[Image:Lfrodrigues-_messaging_config.jpg]]

===Improved search interface===

===Improved history view===

===Administrator reports===

==System Overview==
[[Image:lfrodrigues_system_overview.png]]

==Possible implementarions==
I see two ways of implementing this. My main problem at this stage is that I really don't know if there are real peformance gains with a new system.
===Using Events===
New messages are posted as events. The core messaging code has a handler to grab them and to choose how
to process them.

Martin told me that if the system gets too "popular these messages become COULD be a little heavy on the system".

This approach seams the easiest a better because I would reuse a lot of code (good software practice) but don't know about the performance escalates

===Develop a new class===
I could also implement a completely separate and probably much simpler system where all modules just call a function to add a new message to a queue. The system would the process the messages and choose how to process them.

(I really don't think this can be any more efficient than events, really, and the advantages of using events are too great. If events system doesn't cut it then we can optimise that. -- [[User:Martin Dougiamas|Martin Dougiamas]] 08:31, 15 May 2007 (CDT))

==Plugins==

Plugins should be located under the "message" directory eg:

/message/output/browser (special case, as hooks need to also be included elsewhere as in 1.8)
/message/output/email
/message/output/jabber

The plugins should be full Moodle citizens with db directories, version.php files etc.

==Message Sources==

Somehow all the modules need to register themselves as a *message source* so that the messaging GUI can easily list all the sources.

We could develop something new, or we could extend the [[Development:Events|Events API]] so that modules can optionally use the events.php mechanism to register themselves as known "triggers" (sources) of certain events. I'm inclining strongly toward this latter method.

A catch-all category of "Other messages" would be applied to any unknown incoming messages for which no settings are defined.

Modules will triger an "Register Message Source" event in widget_add_instance() and a "Remove Message Source" in widget_delete_instance() -- Is this correct?

==Changes==
===Files that need changing===

With modules/files need to be adapted to the new system?
* the ones with send email
* ??

===Modules/Files with send emails===

This modules/files send email using email_to_user, is there any other?

Modules:

* journal,
* forum,
* lesson,
* workshop,
* assignment
* exercise

Other files that need changing:
* /lib/moodlelib.php
* /admin/process_email.php
* /enrol/imsenterprise/enrol.php
* /enrol/manual/enrol.php
* /enrol/paypal/ipn.php
* /enrol/flatfile/enrol.php
* /enrol/authorize/uploadcsv.php
* /enrol/authorize/localfuncs.php
* /error/index.php
* /message/lib.php
* /backup/backup_scheduled.php
* /course/pending.php

*./admin/handlevirus.php
*./admin/process_email.php
*./backup/backup_scheduled.php
*./course/pending.php
*./enrol/authorize/enrol.php
*./enrol/authorize/localfuncs.php
*./enrol/authorize/uploadcsv.php
*./enrol/flatfile/enrol.php
*./enrol/imsenterprise/enrol.php
*./enrol/manual/enrol.php
*./enrol/paypal/ipn.php
*./error/index.php
*./lib/moodlelib.php
*./lib/uploadlib.php
*./message/lib.php
*./mod/assignment/lib.php
*./mod/exercise/lib.php
*./mod/forum/lib.php
*./mod/journal/lib.php
*./mod/lesson/essay.php
*./mod/workshop/lib.php

==Other ideas from the community==

*The ability to black-list individual users or groups/groupings site-wide.
*The ability to grey-list individual users or groups/groupings site-wide (only able to IM specified roles at site or course level).
*The ability to add an attachment to IMs (with a maximum size selected at the site level). I would think that this ability could be limited by role, and turned on or off at the site level.
* As a teacher, you want to send different messages at the same time to many students. There should be an option, where teacher selects many individual student or a group of students or the entire class, types in the individual messages next to the student name, and does a one click send to all
* Finding history of messages is very difficult. It needs more options, you should be able to select a period between two dates and find all sent / received messages within those dates.
* The "pop up" window for message is clumsy, and the css is not properly defined
* The message block can presently be used for live chat also, if both participants are online. However, it is not "designed" for the same, more features could be added, allowing one to see who all students of the community are online, and an option to start chat with them.
* Ideally, the live chat element would allow some way to elegantly hold 2 or more separate conversations at once. Currently, this involves having multiple messaging windows open at once and trying to work out who has just said something when it 'dings' in the background is difficult. A tabbed interface like the accordion theme/google chat would be ideal.

==Important Forum Posts==
http://moodle.org/mod/forum/discuss.php?d=63401
http://moodle.org/mod/forum/discuss.php?d=38838

Back: [[Student_projects]]

Student projects/Messaging improvements

2007-06-18T19:27:22Z

Lfrodrigues: /* Modules/Files with send emails */

'''Programmer:''' Luis Filipe Romão Rodrigues

=Summary=
The Moodle messaging system in Moodle is a bit clunky and could use improvements to make it slicker and more efficient as a tool for messaging people within the Moodle environment.

Functionality improvements:
* Add a messaging API class to the core of Moodle which all modules will start using for sending messages (currently they all format their own emails).
* Add output plugins to messaging so that users can choose exactly how to route their messages, especially when they aren't online at the time. Initially the two plugins would be "browser" and "email", but later there could be a jabber plugin, an IRC plugin etc)

Gui improvements:
* Improve the main message GUI using AJAX (Moodle includes the YUI library so you'd need to use that)
* Improve the messaging window to allow chats among three or more other people at once.
* GUI for the output plugins to allow users to set rules about each plugin independently, and also to select from incoming messages by type, by user or by moodle module.
* Improve the methods to search messages and find discussions from the past.
* Improve administrator auditing of message logs, including filtering etc.

=Project Information=

==Mockups==

===User Profile mockup===
[[Image:Lfrodrigues-_messaging_config.jpg]]

===Improved search interface===

===Improved history view===

===Administrator reports===

==System Overview==
[[Image:lfrodrigues_system_overview.png]]

==Possible implementarions==
I see two ways of implementing this. My main problem at this stage is that I really don't know if there are real peformance gains with a new system.
===Using Events===
New messages are posted as events. The core messaging code has a handler to grab them and to choose how
to process them.

Martin told me that if the system gets too "popular these messages become COULD be a little heavy on the system".

This approach seams the easiest a better because I would reuse a lot of code (good software practice) but don't know about the performance escalates

===Develop a new class===
I could also implement a completely separate and probably much simpler system where all modules just call a function to add a new message to a queue. The system would the process the messages and choose how to process them.

(I really don't think this can be any more efficient than events, really, and the advantages of using events are too great. If events system doesn't cut it then we can optimise that. -- [[User:Martin Dougiamas|Martin Dougiamas]] 08:31, 15 May 2007 (CDT))

==Plugins==

Plugins should be located under the "message" directory eg:

/message/output/browser (special case, as hooks need to also be included elsewhere as in 1.8)
/message/output/email
/message/output/jabber

The plugins should be full Moodle citizens with db directories, version.php files etc.

==Message Sources==

Somehow all the modules need to register themselves as a *message source* so that the messaging GUI can easily list all the sources.

We could develop something new, or we could extend the [[Development:Events|Events API]] so that modules can optionally use the events.php mechanism to register themselves as known "triggers" (sources) of certain events. I'm inclining strongly toward this latter method.

A catch-all category of "Other messages" would be applied to any unknown incoming messages for which no settings are defined.

Modules will triger an "Register Message Source" event in widget_add_instance() and a "Remove Message Source" in widget_delete_instance() -- Is this correct?

==Changes==
===Files that need changing===

With modules/files need to be adapted to the new system?
* the ones with send email
* ??

===Modules/Files with send emails===

This modules/files send email using email_to_user, is there any other?

Modules:

* journal,
* forum,
* lesson,
* workshop,
* assignment
* exercise

Other files that need changing:
* /lib/moodlelib.php
* /admin/process_email.php
* /enrol/imsenterprise/enrol.php
* /enrol/manual/enrol.php
* /enrol/paypal/ipn.php
* /enrol/flatfile/enrol.php
* /enrol/authorize/uploadcsv.php
* /enrol/authorize/localfuncs.php
* /error/index.php
* /message/lib.php
* /backup/backup_scheduled.php
* /course/pending.php

==Other ideas from the community==

*The ability to black-list individual users or groups/groupings site-wide.
*The ability to grey-list individual users or groups/groupings site-wide (only able to IM specified roles at site or course level).
*The ability to add an attachment to IMs (with a maximum size selected at the site level). I would think that this ability could be limited by role, and turned on or off at the site level.
* As a teacher, you want to send different messages at the same time to many students. There should be an option, where teacher selects many individual student or a group of students or the entire class, types in the individual messages next to the student name, and does a one click send to all
* Finding history of messages is very difficult. It needs more options, you should be able to select a period between two dates and find all sent / received messages within those dates.
* The "pop up" window for message is clumsy, and the css is not properly defined
* The message block can presently be used for live chat also, if both participants are online. However, it is not "designed" for the same, more features could be added, allowing one to see who all students of the community are online, and an option to start chat with them.
* Ideally, the live chat element would allow some way to elegantly hold 2 or more separate conversations at once. Currently, this involves having multiple messaging windows open at once and trying to work out who has just said something when it 'dings' in the background is difficult. A tabbed interface like the accordion theme/google chat would be ideal.

==Important Forum Posts==
http://moodle.org/mod/forum/discuss.php?d=63401
http://moodle.org/mod/forum/discuss.php?d=38838

Back: [[Student_projects]]

Development:Modules

2007-06-18T17:50:00Z

Lfrodrigues:

'''Activity modules''' reside in the 'mod' directory. Each module is in a separate subdirectory and consists of the following mandatory elements (plus extra scripts unique to each module):

* ''mod.html'' - a form to set up or update an instance of this module
* ''version.php'' - defines some meta-info and provides upgrading code
* ''icon.gif'' - a 16x16 icon for the module
* ''db/'' - SQL dumps of all the required db tables and data (for each database type)
* ''index.php'' - a page to list all instances in a course
* ''view.php'' - a page to view a particular instance
* ''lib.php'' - any/all functions defined by the module should be in here. If the modulename is called widget, then the required functions include:
:* widget_install() - will be called during the installation of the module
:* widget_add_instance() - code to add a new instance of widget
:* widget_update_instance() - code to update an existing instance
:* widget_delete_instance() - code to delete an instance
:* widget_user_outline() - given an instance, return a summary of a user's contribution
:* widget_user_complete() - given an instance, print details of a user's contribution
:* Other functions available but not required are:
:** widget_delete_course() - code to clean up anything that would be leftover after all instances are deleted
:** widget_process_options() - code to pre-process the form data from module settings
:* To avoid possible conflict, any module functions should be named starting with widget_ and any constants you define should start with WIDGET_
* ''config.html'' - (optional) a form to set up or update global settings of this module
* Lastly, each module will have some language files that contain strings for that module.

IMPORTANT: When creating a new module, the new name of the module must not contain numbers or other special characters!

You should also make sure that your activity module provides appropriate support for groups and metacourses.

==See also==

* http://download.moodle.org/download.php/modules/NEWMODULE.zip - new module template for starting module development. Please follow the README instructions inside the zip.
* Using Moodle [http://moodle.org/course/view.php?id=5 Activity modules] forum
* Using Moodle [http://moodle.org/mod/forum/discuss.php?d=66165 A new resource type: where do I put the language strings?] forum discussion
* Using Moodle [http://moodle.org/mod/forum/discuss.php?d=65986 New Module Template Code for Moodle 1.7] forum discussion

[[Category:Developer|Modules]]
[[Category:Modules]]

[[es:Módulos de actividades (desarrollador)]]
[[ja:モジュール (開発者)]]

Student projects/Messaging improvements

2007-06-08T14:02:57Z

Lfrodrigues:

'''Programmer:''' Luis Filipe Romão Rodrigues

=Summary=
The Moodle messaging system in Moodle is a bit clunky and could use improvements to make it slicker and more efficient as a tool for messaging people within the Moodle environment.

Functionality improvements:
* Add a messaging API class to the core of Moodle which all modules will start using for sending messages (currently they all format their own emails).
* Add output plugins to messaging so that users can choose exactly how to route their messages, especially when they aren't online at the time. Initially the two plugins would be "browser" and "email", but later there could be a jabber plugin, an IRC plugin etc)

Gui improvements:
* Improve the main message GUI using AJAX (Moodle includes the YUI library so you'd need to use that)
* Improve the messaging window to allow chats among three or more other people at once.
* GUI for the output plugins to allow users to set rules about each plugin independently, and also to select from incoming messages by type, by user or by moodle module.
* Improve the methods to search messages and find discussions from the past.
* Improve administrator auditing of message logs, including filtering etc.

=Project Information=

==Mockups==

===User Profile mockup===
[[Image:Lfrodrigues-_messaging_config.jpg]]

===Improved search interface===

===Improved history view===

===Administrator reports===

==System Overview==
[[Image:lfrodrigues_system_overview.png]]

==Possible implementarions==
I see two ways of implementing this. My main problem at this stage is that I really don't know if there are real peformance gains with a new system.
===Using Events===
New messages are posted as events. The core messaging code has a handler to grab them and to choose how
to process them.

Martin told me that if the system gets too "popular these messages become COULD be a little heavy on the system".

This approach seams the easiest a better because I would reuse a lot of code (good software practice) but don't know about the performance escalates

===Develop a new class===
I could also implement a completely separate and probably much simpler system where all modules just call a function to add a new message to a queue. The system would the process the messages and choose how to process them.

(I really don't think this can be any more efficient than events, really, and the advantages of using events are too great. If events system doesn't cut it then we can optimise that. -- [[User:Martin Dougiamas|Martin Dougiamas]] 08:31, 15 May 2007 (CDT))

==Plugins==

Plugins should be located under the "message" directory eg:

/message/output/browser (special case, as hooks need to also be included elsewhere as in 1.8)
/message/output/email
/message/output/jabber

The plugins should be full Moodle citizens with db directories, version.php files etc.

==Message Sources==

Somehow all the modules need to register themselves as a *message source* so that the messaging GUI can easily list all the sources.

We could develop something new, or we could extend the [[Development:Events|Events API]] so that modules can optionally use the events.php mechanism to register themselves as known "triggers" (sources) of certain events. I'm inclining strongly toward this latter method.

A catch-all category of "Other messages" would be applied to any unknown incoming messages for which no settings are defined.

Modules will triger an "Register Message Source" event in widget_add_instance() and a "Remove Message Source" in widget_delete_instance() -- Is this correct?

==Changes==
===Files that need changing===

With modules/files need to be adapted to the new system?
* the ones with send email
* ??

===Modules/Files with send emails===

This modules/files send email using email_to_user, is there any other?

Modules:

* journal,
* forum,
* lesson,
* workshop,
* assignment

Other files that need changing:
* /lib/moodlelib.php
* /admin/process_email.php
* /enrol/imsenterprise/enrol.php
* /enrol/manual/enrol.php
* /enrol/paypal/ipn.php
* /enrol/flatfile/enrol.php
* /enrol/authorize/uploadcsv.php
* /enrol/authorize/localfuncs.php
* /error/index.php
* /message/lib.php
* /backup/backup_scheduled.php
* /course/pending.php

==Other ideas from the community==

*The ability to black-list individual users or groups/groupings site-wide.
*The ability to grey-list individual users or groups/groupings site-wide (only able to IM specified roles at site or course level).
*The ability to add an attachment to IMs (with a maximum size selected at the site level). I would think that this ability could be limited by role, and turned on or off at the site level.
* As a teacher, you want to send different messages at the same time to many students. There should be an option, where teacher selects many individual student or a group of students or the entire class, types in the individual messages next to the student name, and does a one click send to all
* Finding history of messages is very difficult. It needs more options, you should be able to select a period between two dates and find all sent / received messages within those dates.
* The "pop up" window for message is clumsy, and the css is not properly defined
* The message block can presently be used for live chat also, if both participants are online. However, it is not "designed" for the same, more features could be added, allowing one to see who all students of the community are online, and an option to start chat with them.

==Important Forum Posts==
http://moodle.org/mod/forum/discuss.php?d=63401
http://moodle.org/mod/forum/discuss.php?d=38838

Back: [[Student_projects]]

Student projects/Messaging improvements

2007-05-23T03:19:26Z

Lfrodrigues: /* Important Forum Posts */

'''Programmer:''' Luis Filipe Romão Rodrigues

=Summary=
The Moodle messaging system in Moodle is a bit clunky and could use improvements to make it slicker and more efficient as a tool for messaging people within the Moodle environment.

Functionality improvements:
* Add a messaging API class to the core of Moodle which all modules will start using for sending messages (currently they all format their own emails).
* Add output plugins to messaging so that users can choose exactly how to route their messages, especially when they aren't online at the time. Initially the two plugins would be "browser" and "email", but later there could be a jabber plugin, an IRC plugin etc)

Gui improvements:
* Improve the main message GUI using AJAX (Moodle includes the YUI library so you'd need to use that)
* Improve the messaging window to allow chats among three or more other people at once.
* GUI for the output plugins to allow users to set rules about each plugin independently, and also to select from incoming messages by type, by user or by moodle module.
* Improve the methods to search messages and find discussions from the past.
* Improve administrator auditing of message logs, including filtering etc.

=Project Information=

==Mockups==

===User Profile mockup===
[[Image:Lfrodrigues-_messaging_config.jpg]]

===Improved search interface===

===Improved history view===

===Administrator reports===

==System Overview==
[[Image:lfrodrigues_system_overview.png]]

==Possible implementarions==
I see two ways of implementing this. My main problem at this stage is that I really don't know if there are real peformance gains with a new system.
===Using Events===
New messages are posted as events. The core messaging code has a handler to grab them and to choose how
to process them.

Martin told me that if the system gets too "popular these messages become COULD be a little heavy on the system".

This approach seams the easiest a better because I would reuse a lot of code (good software practice) but don't know about the performance escalates

===Develop a new class===
I could also implement a completely separate and probably much simpler system where all modules just call a function to add a new message to a queue. The system would the process the messages and choose how to process them.

(I really don't think this can be any more efficient than events, really, and the advantages of using events are too great. If events system doesn't cut it then we can optimise that. -- [[User:Martin Dougiamas|Martin Dougiamas]] 08:31, 15 May 2007 (CDT))

==Plugins==

Plugins should be located under the "message" directory eg:

/message/output/browser (special case, as hooks need to also be included elsewhere as in 1.8)
/message/output/email
/message/output/jabber

The plugins should be full Moodle citizens with db directories, version.php files etc.

==Message Sources==

Somehow all the modules need to register themselves as a *message source* so that the messaging GUI can easily list all the sources.

We could develop something new, or we could extend the [[Development:Events|Events API]] so that modules can optionally use the events.php mechanism to register themselves as known "triggers" (sources) of certain events. I'm inclining strongly toward this latter method.

A catch-all category of "Other messages" would be applied to any unknown incoming messages for which no settings are defined.

==Changes==
===Files that need changing===

With modules/files need to be adapted to the new system?
* the ones with send email
* ??

===Modules/Files with send emails===

This modules/files send email using email_to_user, is there any other?

Modules:

* journal,
* forum,
* lesson,
* workshop,
* assignment

Other files that need changing:
* /lib/moodlelib.php
* /admin/process_email.php
* /enrol/imsenterprise/enrol.php
* /enrol/manual/enrol.php
* /enrol/paypal/ipn.php
* /enrol/flatfile/enrol.php
* /enrol/authorize/uploadcsv.php
* /enrol/authorize/localfuncs.php
* /error/index.php
* /message/lib.php
* /backup/backup_scheduled.php
* /course/pending.php

==Other ideas from the community==

*The ability to black-list individual users or groups/groupings site-wide.
*The ability to grey-list individual users or groups/groupings site-wide (only able to IM specified roles at site or course level).
*The ability to add an attachment to IMs (with a maximum size selected at the site level). I would think that this ability could be limited by role, and turned on or off at the site level.
* As a teacher, you want to send different messages at the same time to many students. There should be an option, where teacher selects many individual student or a group of students or the entire class, types in the individual messages next to the student name, and does a one click send to all
* Finding history of messages is very difficult. It needs more options, you should be able to select a period between two dates and find all sent / received messages within those dates.
* The "pop up" window for message is clumsy, and the css is not properly defined
* The message block can presently be used for live chat also, if both participants are online. However, it is not "designed" for the same, more features could be added, allowing one to see who all students of the community are online, and an option to start chat with them.

==Important Forum Posts==
http://moodle.org/mod/forum/discuss.php?d=63401
http://moodle.org/mod/forum/discuss.php?d=38838

Back: [[Student_projects]]

Student projects/Messaging improvements

2007-05-23T03:18:03Z

Lfrodrigues:

'''Programmer:''' Luis Filipe Romão Rodrigues

=Summary=
The Moodle messaging system in Moodle is a bit clunky and could use improvements to make it slicker and more efficient as a tool for messaging people within the Moodle environment.

Functionality improvements:
* Add a messaging API class to the core of Moodle which all modules will start using for sending messages (currently they all format their own emails).
* Add output plugins to messaging so that users can choose exactly how to route their messages, especially when they aren't online at the time. Initially the two plugins would be "browser" and "email", but later there could be a jabber plugin, an IRC plugin etc)

Gui improvements:
* Improve the main message GUI using AJAX (Moodle includes the YUI library so you'd need to use that)
* Improve the messaging window to allow chats among three or more other people at once.
* GUI for the output plugins to allow users to set rules about each plugin independently, and also to select from incoming messages by type, by user or by moodle module.
* Improve the methods to search messages and find discussions from the past.
* Improve administrator auditing of message logs, including filtering etc.

=Project Information=

==Mockups==

===User Profile mockup===
[[Image:Lfrodrigues-_messaging_config.jpg]]

===Improved search interface===

===Improved history view===

===Administrator reports===

==System Overview==
[[Image:lfrodrigues_system_overview.png]]

==Possible implementarions==
I see two ways of implementing this. My main problem at this stage is that I really don't know if there are real peformance gains with a new system.
===Using Events===
New messages are posted as events. The core messaging code has a handler to grab them and to choose how
to process them.

Martin told me that if the system gets too "popular these messages become COULD be a little heavy on the system".

This approach seams the easiest a better because I would reuse a lot of code (good software practice) but don't know about the performance escalates

===Develop a new class===
I could also implement a completely separate and probably much simpler system where all modules just call a function to add a new message to a queue. The system would the process the messages and choose how to process them.

(I really don't think this can be any more efficient than events, really, and the advantages of using events are too great. If events system doesn't cut it then we can optimise that. -- [[User:Martin Dougiamas|Martin Dougiamas]] 08:31, 15 May 2007 (CDT))

==Plugins==

Plugins should be located under the "message" directory eg:

/message/output/browser (special case, as hooks need to also be included elsewhere as in 1.8)
/message/output/email
/message/output/jabber

The plugins should be full Moodle citizens with db directories, version.php files etc.

==Message Sources==

Somehow all the modules need to register themselves as a *message source* so that the messaging GUI can easily list all the sources.

We could develop something new, or we could extend the [[Development:Events|Events API]] so that modules can optionally use the events.php mechanism to register themselves as known "triggers" (sources) of certain events. I'm inclining strongly toward this latter method.

A catch-all category of "Other messages" would be applied to any unknown incoming messages for which no settings are defined.

==Changes==
===Files that need changing===

With modules/files need to be adapted to the new system?
* the ones with send email
* ??

===Modules/Files with send emails===

This modules/files send email using email_to_user, is there any other?

Modules:

* journal,
* forum,
* lesson,
* workshop,
* assignment

Other files that need changing:
* /lib/moodlelib.php
* /admin/process_email.php
* /enrol/imsenterprise/enrol.php
* /enrol/manual/enrol.php
* /enrol/paypal/ipn.php
* /enrol/flatfile/enrol.php
* /enrol/authorize/uploadcsv.php
* /enrol/authorize/localfuncs.php
* /error/index.php
* /message/lib.php
* /backup/backup_scheduled.php
* /course/pending.php

==Other ideas from the community==

*The ability to black-list individual users or groups/groupings site-wide.
*The ability to grey-list individual users or groups/groupings site-wide (only able to IM specified roles at site or course level).
*The ability to add an attachment to IMs (with a maximum size selected at the site level). I would think that this ability could be limited by role, and turned on or off at the site level.
* As a teacher, you want to send different messages at the same time to many students. There should be an option, where teacher selects many individual student or a group of students or the entire class, types in the individual messages next to the student name, and does a one click send to all
* Finding history of messages is very difficult. It needs more options, you should be able to select a period between two dates and find all sent / received messages within those dates.
* The "pop up" window for message is clumsy, and the css is not properly defined
* The message block can presently be used for live chat also, if both participants are online. However, it is not "designed" for the same, more features could be added, allowing one to see who all students of the community are online, and an option to start chat with them.

==Important Forum Posts==
http://moodle.org/mod/forum/discuss.php?d=63401

Back: [[Student_projects]]

Student projects/Messaging improvements

2007-05-10T16:20:43Z

Lfrodrigues: /* System Overview */

File:lfrodrigues system overview.png

2007-05-10T16:20:11Z

Lfrodrigues:

Student projects/Messaging improvements

2007-05-10T16:19:27Z

Lfrodrigues: /* System Overview */

Student projects/Messaging improvements

2007-05-10T16:19:00Z

Lfrodrigues:

Student projects/Messaging improvements

2007-05-07T17:55:25Z

Lfrodrigues:

Student projects/Messaging improvements

2007-05-07T17:55:02Z

Lfrodrigues:

Student projects/Messaging improvements

2007-05-07T15:31:41Z

Lfrodrigues: /* Files that need channging */

Student projects/Messaging improvements

2007-05-07T15:31:23Z

Lfrodrigues:

File:Lfrodrigues- messaging config.jpg

2007-05-07T15:27:01Z

Lfrodrigues: Initial mockup for the messaging profile options

Initial mockup for the messaging profile options

Student projects/Messaging improvements

2007-05-07T15:00:18Z

Lfrodrigues:

Student projects/Messaging improvements

2007-05-05T13:07:54Z

Lfrodrigues: /* Logs */

'''Programmer:''' Luis Filipe Romão Rodrigues

The Moodle messaging system in Moodle is a bit clunky and could use improvements to make it slicker and more efficient as a tool for messaging people within the Moodle environment.

Functionality improvements:
* Add a messaging API class to the core of Moodle which all modules will start using for sending messages (currently they all format their own emails).
* Add output plugins to messaging so that users can choose exactly how to route their messages, especially when they aren't online at the time. Initially the two plugins would be "browser" and "email", but later there could be a jabber plugin, an IRC plugin etc)

Gui improvements:
* Improve the main message GUI using AJAX (Moodle includes the YUI library so you'd need to use that)
* Improve the messaging window to allow chats among three or more other people at once.
* GUI for the output plugins to allow users to set rules about each plugin independently, and also to select from incoming messages by type, by user or by moodle module.
* Improve the methods to search messages and find discussions from the past.
* Improve administrator auditing of message logs, including filtering etc.

== Notes ==

With modules/files need to be adapted to the new system?
* the ones with send email
* ??

== Modules/Files with send emails ==

This modules/files send email using email_to_user, is there any other?

Modules:

* journal,
* forum,
* lesson,
* workshop,
* assignment

Other files that need changing:
* /lib/moodlelib.php
* /admin/process_email.php
* /enrol/imsenterprise/enrol.php
* /enrol/manual/enrol.php
* /enrol/paypal/ipn.php
* /enrol/flatfile/enrol.php
* /enrol/authorize/uploadcsv.php
* /enrol/authorize/localfuncs.php
* /error/index.php
* /message/lib.php
* /backup/backup_scheduled.php
* /course/pending.php

Back: [[Student_projects]]

Student projects/Messaging improvements

2007-05-05T13:03:00Z

Lfrodrigues:

'''Programmer:''' Luis Filipe Romão Rodrigues

The Moodle messaging system in Moodle is a bit clunky and could use improvements to make it slicker and more efficient as a tool for messaging people within the Moodle environment.

Functionality improvements:
* Add a messaging API class to the core of Moodle which all modules will start using for sending messages (currently they all format their own emails).
* Add output plugins to messaging so that users can choose exactly how to route their messages, especially when they aren't online at the time. Initially the two plugins would be "browser" and "email", but later there could be a jabber plugin, an IRC plugin etc)

Gui improvements:
* Improve the main message GUI using AJAX (Moodle includes the YUI library so you'd need to use that)
* Improve the messaging window to allow chats among three or more other people at once.
* GUI for the output plugins to allow users to set rules about each plugin independently, and also to select from incoming messages by type, by user or by moodle module.
* Improve the methods to search messages and find discussions from the past.
* Improve administrator auditing of message logs, including filtering etc.

=== Logs ===

Modules that send emails, will use the new system:
journal, forum, lesson, workshop, assignment

Other files that need changing:
/lib/moodlelib.php

./admin/process_email.php

./enrol/imsenterprise/enrol.php

./enrol/manual/enrol.php

./enrol/paypal/ipn.php

./enrol/flatfile/enrol.php

./enrol/authorize/uploadcsv.php

./enrol/authorize/localfuncs.php

./error/index.php

./message/lib.php

./backup/backup_scheduled.php

./course/pending.php

Back: [[Student_projects]]