A couple weeks ago, we had a major issue with students abusing IMs in one of our Moodle installations, and I was facing a crisis where I would have to turn off all messaging. I say a crisis, because we have a lot of it, and well over 90% of the IMs are constructive, and I really didn't like the choice of all or nothing.
It took me a few hours, but I was able to take the Enhanced Messaging hack built for Moodle 1.5.3 and apply it to our Moodle 1.8.2 install. I've had this on a couple of test installs and added it to our troubled Moodle install and it seems to be working just fine.
I am now comfortable making this available to the rest of the Moodle community and will do my best to help support it. I have just added it to the Blocks and Modules Database at http://moodle.org/mod/data/view.php?d=13&rid=1045 and it should be available soon, after it's been approved.
Please let me know if you have any questions.
Thanks,
Matt
This hack looks good on the surface Matt.
Can you also put an option in the grey list as to whether this group can only IM the teacher or everyone .... or is it implied?
larry
Can you also put an option in the grey list as to whether this group can only IM the teacher or everyone .... or is it implied?
larry
The option you want looks like you really only need a blacklist and a whitelist, and then you can put in a statement to handle checking to see if the user is on the whitelist to allow the message. If this is what you're looking for, let me know and I'll figure out the code and send it to you to try out.
Here's the default rules, and you can look at how they're handled in /message/send.php.
Blacklisted users cannot send messages to anyone at any time. They can receive messages from whitelisted users only. We put students on the blacklist at our instructors' requests or if the transcripts show inappropriate discussions.
Greylisted users can send messages to other greylisted users and to whitelisted users. If time restrictions have been applied, greylisted users are subject to those restrictions. By default, all users start on the greylist.
Whitelisted users can send messages to any user at any time, no matter if they are black or greylisted, or if time restrictions are in place. The only users we place on our whitelist are staff.
Thanks,
Matt
Here's the default rules, and you can look at how they're handled in /message/send.php.
Blacklisted users cannot send messages to anyone at any time. They can receive messages from whitelisted users only. We put students on the blacklist at our instructors' requests or if the transcripts show inappropriate discussions.
Greylisted users can send messages to other greylisted users and to whitelisted users. If time restrictions have been applied, greylisted users are subject to those restrictions. By default, all users start on the greylist.
Whitelisted users can send messages to any user at any time, no matter if they are black or greylisted, or if time restrictions are in place. The only users we place on our whitelist are staff.
Thanks,
Matt
Matt
The use of three lists make sense. I now better understand the capabilities of each list. The feature I suggested, could be accomplished with the inclusion of a checkbox on the blacklist so that the teacher could decide whether users on that list could send to no one or only to users with teacher/non-editing teacher status.
One more question .... Is this course based, rather than site based? I'm assuming that users can only IM other users within their own course. Is this correct? If it is site based instead, then an added restriction for the grey list could be to limit it to the course participants only.
cheers
larry
The use of three lists make sense. I now better understand the capabilities of each list. The feature I suggested, could be accomplished with the inclusion of a checkbox on the blacklist so that the teacher could decide whether users on that list could send to no one or only to users with teacher/non-editing teacher status.
One more question .... Is this course based, rather than site based? I'm assuming that users can only IM other users within their own course. Is this correct? If it is site based instead, then an added restriction for the grey list could be to limit it to the course participants only.
cheers
larry
This looks excellent, we have had to restrict messaging to pupil - teacher only, I'm looking forward to testing this out, my only concern will be when it is time to upgrade to 1.9. I missed out 1.6 and 1.7 to keep the previous message hack.
Rick
Rick
My instructors really fought to keep messaging and my administration is happy with this solution. I am planning to upgrade to 1.9 during our winter break, so I will need to continue to support this capability. I will start looking at it sometime in December and release a 1.9 version if one is needed.
Thanks,
Matt
Thanks,
Matt
Thats excellent news. I'll have a practice or 2 installing it and if I have no problems then I'll go live later next week.
Rick.
Rick.
Matt - I'm glad to hear that your teachers fought the good fight and appreciate your contributions to the messaging capabilities of Moodle. As for future development, have you checked out:
http://docs.moodle.org/en/Student_projects/Messaging_improvements and also MDL-10107?
How might your work be incorporated into this? For me, the goal of a good patch is to have it become integrated into Moodle core and/or to become obsolete. So the 1.9 release might be to blend in your improvements with the ones being made although I have not had a chance to check out the new functionality in 1.9.
Peace - Anthony
http://docs.moodle.org/en/Student_projects/Messaging_improvements and also MDL-10107?
How might your work be incorporated into this? For me, the goal of a good patch is to have it become integrated into Moodle core and/or to become obsolete. So the 1.9 release might be to blend in your improvements with the ones being made although I have not had a chance to check out the new functionality in 1.9.
Peace - Anthony
From what I can tell, only a little of the code from the student project has been/will be added to 1.9 - see http://moodle.org/mod/forum/discuss.php?d=76255 - it looks like the changes will mostly be with the use of Events to handle messages, but I don't see that any of it has been committed to 1.9 yet.
Without seeing Luis Rodrigues' code, I don't know how well it will integrate. This enhancement is in the project under 'Other ideas from the community', but I don't know if it's been looked at.
I think the best way to do this would be get a determination from MartinD as to where this student project is, if at all, on the Roadmap, and then decide if this needs to be a tracker issue as a new feature. I can think of three things that would really need to be addressed before it could be submitted to core: automatic creation of database tables, remove requirement that users must be site students (maybe just authenticated users?), and adding search functionality to the greylist.
Thanks,
Matt
Without seeing Luis Rodrigues' code, I don't know how well it will integrate. This enhancement is in the project under 'Other ideas from the community', but I don't know if it's been looked at.
I think the best way to do this would be get a determination from MartinD as to where this student project is, if at all, on the Roadmap, and then decide if this needs to be a tracker issue as a new feature. I can think of three things that would really need to be addressed before it could be submitted to core: automatic creation of database tables, remove requirement that users must be site students (maybe just authenticated users?), and adding search functionality to the greylist.
Thanks,
Matt
Matt - I'll see what I can do to get a hold of the code so you can evaluate it and check with MartinD to get an update on where the work with the messenger is headed. I'm not concerned about the creation of the tables as we can easily resolve that I just have not had a chance to do it - but if you want go ahead and proceed with creating a custom block for administering the Enhanced Messaging features and add the code in there (or use the /local/db folder option). Keep up the good work. Peace - Anthony
Just a quick note to let everyone know that the patch works cleanly when applied to Moodle 1.9 - there are a couple of small changes in Messaging, so it wouldn't be wise to apply the 1.8.2 patch to 1.9, but I'll release the 1.9 patch in a couple weeks, after I've gotten a chance to see that it's working on our production site (our students are on break right now and I'm not getting heavy usage!).
There is one issue I've come across - you don't get a list right now if you have a default role set for users on the front page. I've filed this as a bug (MDL-12737).
Thanks,
Matt
There is one issue I've come across - you don't get a list right now if you have a default role set for users on the front page. I've filed this as a bug (MDL-12737).
Thanks,
Matt
This hack is site based. It is possible to modify it so teachers could get to it from their courses and assign users to the lists, but what I found in this is that since messaging is enabled at the site level, all students had to do was go to out of the course and go to their profile, and then they could message anyone. Since that meant I would have to apply this at the site level, that's the way I coded it.
I just don't see that limiting messaging within the course will effectively stop users from messaging in other areas of the site. I may be wrong on this, but the majority of our users were messaging outside the course, and the instructors couldn't see it in the activity logs. By doing it at the site level, blacklisted users can't message at any level.
Thanks,
Matt
I just don't see that limiting messaging within the course will effectively stop users from messaging in other areas of the site. I may be wrong on this, but the majority of our users were messaging outside the course, and the instructors couldn't see it in the activity logs. By doing it at the site level, blacklisted users can't message at any level.
Thanks,
Matt
Hi Matt
We currently use the hack that only allow students to PM their teacher. But unfortunately the same box is used for teacher PD. So currently, it is all or nothing.
Some senior high students were making unsolicited messages to members not known to them, after they found their names in the who's online block. We removed the who's online block to limit who students could see. Then we resorted to the aforementioned hack.
As there is really no admin assigned to play PM cop, it would be much ibetter in our situation to localize it to the teachers and let them handle their own PM issues. We only want students to be able to PM fellow course mates. Failing that, we will have to live with the current scenario.
cheers
larry
We currently use the hack that only allow students to PM their teacher. But unfortunately the same box is used for teacher PD. So currently, it is all or nothing.
Some senior high students were making unsolicited messages to members not known to them, after they found their names in the who's online block. We removed the who's online block to limit who students could see. Then we resorted to the aforementioned hack.
As there is really no admin assigned to play PM cop, it would be much ibetter in our situation to localize it to the teachers and let them handle their own PM issues. We only want students to be able to PM fellow course mates. Failing that, we will have to live with the current scenario.
cheers
larry
Sorry I didn't get back to you sooner - Thanksgiving holiday here in the U.S.
Do you want to make a couple of modifications and let me know if this will work for you to allow your teachers to use the enhanced messaging hack? This should allow teachers to access the enhanced messaging from their courses, instead of having the administrator do it.
In /message/levels.php, change line 24 to:
require_capability('moodle/course:update', get_context_instance(CONTEXT_SYSTEM, $courseid));
Then in /blocks/admin/block_admin.php, wherever it's best for your teachers, but I would imagine it's either after roles assignment or course reports, add the following:
if (has_capability'moodle/course:update', get_context_instance(CONTEXT_SYSTEM, $courseid)) {
$this->content->items[]='<a href="'.$CFG->wwwroot.'/'.$CFG->admin.'/message/levels.php?courseid='.$course->id.'">'.get_string('adminenhmess', 'admin').'</a>';
$this->content->icons[]='<img src="'.$CFG->pixpath.'/i/messagelevels.gif" class="icon" alt="" />';
}
You'll need to come up with an icon for messagelevels.gif and place it in either /pix/i/ or /YOURTHEME/pix/i/.
I haven't tried this myself, so please set it up on a test box and let me know what kind of results you are getting - we may need to make some changes to this code.
Thanks,
Matt
Do you want to make a couple of modifications and let me know if this will work for you to allow your teachers to use the enhanced messaging hack? This should allow teachers to access the enhanced messaging from their courses, instead of having the administrator do it.
In /message/levels.php, change line 24 to:
require_capability('moodle/course:update', get_context_instance(CONTEXT_SYSTEM, $courseid));
Then in /blocks/admin/block_admin.php, wherever it's best for your teachers, but I would imagine it's either after roles assignment or course reports, add the following:
if (has_capability'moodle/course:update', get_context_instance(CONTEXT_SYSTEM, $courseid)) {
$this->content->items[]='<a href="'.$CFG->wwwroot.'/'.$CFG->admin.'/message/levels.php?courseid='.$course->id.'">'.get_string('adminenhmess', 'admin').'</a>';
$this->content->icons[]='<img src="'.$CFG->pixpath.'/i/messagelevels.gif" class="icon" alt="" />';
}
You'll need to come up with an icon for messagelevels.gif and place it in either /pix/i/ or /YOURTHEME/pix/i/.
I haven't tried this myself, so please set it up on a test box and let me know what kind of results you are getting - we may need to make some changes to this code.
Thanks,
Matt
Thanks Matt
No pbm on the timing
I'll get at testing it today or tomorrow and report back
larry
No pbm on the timing
I'll get at testing it today or tomorrow and report back
larry
Hey Jason,
Did you see the post about having to manually edit the times in the database? I had a similar issue to yours until I added the "0" that was stripped from the database upon save. Users could send messages and the hack didn't work right until I edited the database.
This might help you.
Once I fixed the times, all worked as it was supposed to.
-Chris
Did you see the post about having to manually edit the times in the database? I had a similar issue to yours until I added the "0" that was stripped from the database upon save. Users could send messages and the hack didn't work right until I edited the database.
This might help you.
Once I fixed the times, all worked as it was supposed to.
-Chris
I had the same idea and applied for CVS access to contrib earlier today - I've now got two blocks and this hack that I'd like to get into CVS. I haven't ever uploaded into CVS, but I think the Moodle docs should help me figure it out!
If you would like to upload it while I'm waiting for access, I would appreciate it.
Thanks,
Matt
If you would like to upload it while I'm waiting for access, I would appreciate it.
Thanks,
Matt
Hi,
I have installed this onto one of our Moodle installations which is running 1.83+ and it wont move any of the users into the lists or allow us to set a time to restrict access to messaging. I have run the sql database file using phpmyadmin and it successfully created the tables but its not adding anything into them when you try to add users to the lists.
any ideas why this is not working or is it broken in 1.83+ ?
thanks
Mark
I have installed this onto one of our Moodle installations which is running 1.83+ and it wont move any of the users into the lists or allow us to set a time to restrict access to messaging. I have run the sql database file using phpmyadmin and it successfully created the tables but its not adding anything into them when you try to add users to the lists.
any ideas why this is not working or is it broken in 1.83+ ?
thanks
Mark
>>it wont move any of the users into the lists
Does anyone show up in the greylist? Would you check Front Page->Front Page Roles and make sure all your users are assigned the student role?
>>allow us to set a time to restrict access to messaging
Would you run the following query and let me know what you get?
SELECT * FROM `mdl_message_access`
Thanks,
Matt
Does anyone show up in the greylist? Would you check Front Page->Front Page Roles and make sure all your users are assigned the student role?
>>allow us to set a time to restrict access to messaging
Would you run the following query and let me know what you get?
SELECT * FROM `mdl_message_access`
Thanks,
Matt
Hi,
Yes I can see everybody in the grey list, i moved them into the role using the Front page roles. That part is working but when you select a user nothing happens...
But i think i can see what has happened, in the database it has made to tables called prefix_message_access and prefix_message_access_users..
I guess by your select query they should be named mdl_message_access and mdl_message_access_users...
I have renamed the tables but it still does not work, any more ideas?
Thanks
Mark
Yes I can see everybody in the grey list, i moved them into the role using the Front page roles. That part is working but when you select a user nothing happens...
But i think i can see what has happened, in the database it has made to tables called prefix_message_access and prefix_message_access_users..
I guess by your select query they should be named mdl_message_access and mdl_message_access_users...
I have renamed the tables but it still does not work, any more ideas?
Thanks
Mark
Are you just trying to use the time restrictions for the greylist, or are you trying to move them into white/blacklists?
The time restrictions apply to all users in the greylist, and I'd need the results of the query I sent you earlier to figure that one out.
To move users from the greylist to one of the other lists, select the user and then click on the appropriate button below the greylist.
Thanks,
Matt
The time restrictions apply to all users in the greylist, and I'd need the results of the query I sent you earlier to figure that one out.
To move users from the greylist to one of the other lists, select the user and then click on the appropriate button below the greylist.
Thanks,
Matt
I have the same issue. I'm running Moodle 1.8.4+ and nothing happens when I try to move a user to a different list, or set the access restriction times. A look into my database revealed that no data is being written into the tables.
Any ideas?
~ Bryce
Any ideas?
~ Bryce
I've made a fix for 1.9 that I haven't released yet, it may be a fix for this issue - but I don't have a 1.8.3 or 1.8.4 test install set up right now, so would you give this a try and let me know?
I've got two changes I'd like you to make.
In /message/lib.php, search for 'function message_access_update($course = SITEID) {'
Then look for the following line:
if (!$courseusers = get_course_users($course)) {
Change it to:
if (!$courseusers = get_course_students($course)) {
Second, in /message/levels.php, search for the following:
if ($users = get_course_users($courseid, 'lastname ASC')) {
Change it to:
if ($users = get_course_students($courseid, 'lastname ASC')) {
Let me know how this works for you.
Thanks,
Matt
I've got two changes I'd like you to make.
In /message/lib.php, search for 'function message_access_update($course = SITEID) {'
Then look for the following line:
if (!$courseusers = get_course_users($course)) {
Change it to:
if (!$courseusers = get_course_students($course)) {
Second, in /message/levels.php, search for the following:
if ($users = get_course_users($courseid, 'lastname ASC')) {
Change it to:
if ($users = get_course_students($courseid, 'lastname ASC')) {
Let me know how this works for you.
Thanks,
Matt
Thanks for your reply, Matt!
I made the changes you stated above, but I still can't move users to the other lists or set access restriction times. No data is being written to the tables on my MySQL database. I'm running MySQL 5.0.22, PHP version 5, and Apache 2.2.3.
Thanks for you help!
~ Bryce
I made the changes you stated above, but I still can't move users to the other lists or set access restriction times. No data is being written to the tables on my MySQL database. I'm running MySQL 5.0.22, PHP version 5, and Apache 2.2.3.
Thanks for you help!
~ Bryce
Ouch. While the command to get the student list has changed, the restriction times have been pretty solid.
Would you set debugging to all and let me know what messages you get?
Thanks,
Matt
Would you set debugging to all and let me know what messages you get?
Thanks,
Matt
With the release of 1.9 stable right around the corner, do you have the 1.9 messaging fix? I will not be updating to 1.9 without the messaging fix. This fix is critical for us to maintain learning in the classroom and keeping students on track with the teacher.
After school, students can chat all night long.
After school, students can chat all night long.
New version works with Moodle 1.9plus
Please see the following post: http://moodle.org/mod/forum/discuss.php?d=94765
I started a new discussion on this as I have managed to get the old message enhancements block to work in Moodle 1.8.4 and 1.9 plus.
Cheers,
Eddie
Please see the following post: http://moodle.org/mod/forum/discuss.php?d=94765
I started a new discussion on this as I have managed to get the old message enhancements block to work in Moodle 1.8.4 and 1.9 plus.
Cheers,
Eddie
Hi Matt
I have been testing your hack on our 1.8.1 Moodle (using PostgreSQL). I had the problems with the users not being moved from the grey list to the black - the call to insert_record() was failing. I fixed it by changing the field name in the message_access_users table from "user" to "userid". It seems to work ok now.
I also had an initial problem because our front page course id is not 1, so I made a small change in admin\settings\users.php to put the correct course id in.
We will find this enhancement really useful - thanks for your work.
Barbara
I have been testing your hack on our 1.8.1 Moodle (using PostgreSQL). I had the problems with the users not being moved from the grey list to the black - the call to insert_record() was failing. I fixed it by changing the field name in the message_access_users table from "user" to "userid". It seems to work ok now.
I also had an initial problem because our front page course id is not 1, so I made a small change in admin\settings\users.php to put the correct course id in.
We will find this enhancement really useful - thanks for your work.
Barbara
I am so glad that someone has managed to update this 'mod'. You are 'worth your weight in gold', many thanks.
At college we had the original hack installed but had to leave it behind when we upgraded to 1.8.x, the original database tables were, however, still on the system.
I installed the files at college Friday night and sorted out who should be in which list over the weekend, I also set the times to Start 0900 and End 1600.
On checking the logs I was concerned to discover that messages were being sent and received in the period that I had thought messaging for the 'grey-list' was turned off.
What can I do to ensure that the time limits are adhered to?
Despite this it is still a wonderful 'hack'.
*edit*
I have just looked at the database and noticed that the Start time was shown as 090 and the end time 160 could this be the reason? I have amended them to 0900 and 1600.
Ian
That would be the reason. Thanks for letting me know about this.
It looks like the dropdown selection is stripping the '00' to just '0' in the database when you select something on the hour. I've been drafted today as a high-priced technician to remove old cash register training machines from one of our classrooms, so I'm not going to be able to even look at the code today, but will dig into it and see what it will take to fix it. Once I've updated the version in the database and on CVS, I'll post a note here to that effect - until then, I think the workaround will be to either not use start and end times that are on the hour, or go into the database and edit them after you set it.
Thanks,
Matt
It looks like the dropdown selection is stripping the '00' to just '0' in the database when you select something on the hour. I've been drafted today as a high-priced technician to remove old cash register training machines from one of our classrooms, so I'm not going to be able to even look at the code today, but will dig into it and see what it will take to fix it. Once I've updated the version in the database and on CVS, I'll post a note here to that effect - until then, I think the workaround will be to either not use start and end times that are on the hour, or go into the database and edit them after you set it.
Thanks,
Matt
Hello Matt,
First, THANK YOU!
Second...Thanks again for your hard work!!!! This is awesome! Teachers across the district are rejoicing.
Have a wonderful Christmas, You just made ours!
Thanks,
Chris
First, THANK YOU!
Second...Thanks again for your hard work!!!! This is awesome! Teachers across the district are rejoicing.
Have a wonderful Christmas, You just made ours!
Thanks,
Chris
Hello Matt,
Thanks,
Chris
- If I wanted to have teachers in the white, how can I do this easily? We have just under 6000 users currently and it grows every month as more teachers bring their courses online. (Not a big deal, just wondering if there is a simple solution)
- When a new student signs up or logs in, how do I ensure they are placed in the restricted section automatically? We have an LDAP login, so new people login all the time.
Thanks,
Chris
1. I'd like to figure out how to put a search box under the greylist so you can search users and then place them in white or black as needed. I'm much more of a hacker/debugger than a coder, so I haven't been very successful at this yet. If I can figure it out (or if someone else does and sends me the code), I'll get it implemented. Otherwise, it's a manual search. 
2. We have probably about half the users you have, also using LDAP, and right now, one of my co-workers hits the front page roles every day and moves anyone new into the student role. When 1.9 comes around, you'll be able to set this up in site administration.
Thanks,
Matt
2. We have probably about half the users you have, also using LDAP, and right now, one of my co-workers hits the front page roles every day and moves anyone new into the student role. When 1.9 comes around, you'll be able to set this up in site administration.
Thanks,
Matt
Hey Matt (or other coders),
1. Is there a way to automatically trigger "white list" permissions based on site roles? All our teachers are given course creator roles based on their ldap group within the ldap login settings.
I can't say this enough... this type of functionality is MUCH needed in the k12 environment (Built into Moodle Message Core) and this has been a joyous week for our teachers since I implemented this hack!!! Students are on task and following instruction during class time and they can now IM till their fingers fall off after school while working on homework.
-Chris
1. Is there a way to automatically trigger "white list" permissions based on site roles? All our teachers are given course creator roles based on their ldap group within the ldap login settings.
I can't say this enough... this type of functionality is MUCH needed in the k12 environment (Built into Moodle Message Core) and this has been a joyous week for our teachers since I implemented this hack!!! Students are on task and following instruction during class time and they can now IM till their fingers fall off after school while working on homework.
-Chris