Student projects/Messaging improvements: Difference between revisions
No edit summary |
|||
Line 99: | Line 99: | ||
* /course/pending.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. | |||
Revision as of 08:40, 17 May 2007
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
Improved search interface
Improved history view
Administrator reports
System Overview
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. -- 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 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.
Back: Student_projects