Messaging Report

Messaging Report

by David Gray -
Number of replies: 7

A while back, I posted some suggestions in the tracker on how to improve the messaging function of Moodle in 2.0 (MDL-16000). I got impatient and a little bored at work, so I sat down and wrote a simple admin report that can show you the last x many messages sent to users on the system. I use it all the time to track down bullying and misuse of the messaging system. Right now it's VERY simple (pagination sort of works, but is buggy and there's no filtering options available) but I thought I'd post it here for Moodle admins to check out, and for developers to have a squiz at.

This is my second Moodle contribution (my first being a theme) and I found the documentation not very helpful for basic things like database calls and getting user information, but I think I did alright(?). I'm seeking feedback on my code and the report's usability, plus perhaps a few feature requests. On my chopping block:

  • Filter results by username, role or by keywords
  • Tighter integration with Moodle code
  • Choose how many messages to display etc.
  • Fix the sorting
  • Fix the pagination code
  • Clean up the code
  • Add a custom admin page so this code won't have to piggyback the simpletest report

Plus a few other things. Installation is simple. Just unzip the zip at the root of Moodle and then run the report from the administration box.

Let me know what you think, how I could improve it and whatever else you think would be relevant or useful. Cheers smile

Average of ratings: -
In reply to David Gray

Re: Messaging Report

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
We have a home for useful third party code like this, called Contrib. It sounds like this should be added, thought I have not actually tried it (yet).
Average of ratings: -
In reply to David Gray

Re: Messaging Report

by Mich P -
Tested this on 1.9.3 weekly and it is great!

The only thing that was a problem was the user links (not using the Moodle root, just the domain + "/user/view.php etc"), but other than that very cool.

It is definitely a useful report.

thanks!
Average of ratings: -
In reply to Mich P

Re: Messaging Report

by David Gray -

Thanks Mich. The first version had our Moodle server hard-coded into it blush

I'll have a look at that and see if I can patch it up later today :D

Average of ratings: -
In reply to David Gray

Re: Messaging Report

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Code review comments. It is generally very good, which is why I have criticised you for every little thing I could find wink

moodle/site:viewreports or moodle/site:readallmessages would be a better capability that moodle/site:doanything

Surely there is no need to steal the simpletest report's place in the tree. I think you will find that there is a page reportmessaging automatically created in the tree that you can use.

Don't acces $_GET directly. Use optional_param from lib/moodlelib.php, with an appropriate param type (PARAM_BOOL, PARAM_INT, PARAM_INT and PARAM_ALPHA, I am guessing - in order for the 4 things you access from $_GET). Think what would happen if someone hit your script with the URL .../messages.php?sortby='timecreated; DROP TABLE mdl_user; ...'. Classic security hole.

recordset_to_array(get_recordset_sql( is the same as the more normal get_records_sql. Actually, since you are not doing anything sophisticated in the SQL you can use plain get_records.

Use the $limitfrom and $limitnum parameters on get_records_sql, or it won't work on all DB's.

I don't really see what you gain by making outputTable and doNav functions, other than stopping people reading the code linearly.

Look at print_table from lib/weblib.php. Actually, it is probably easier to look for other places where it is used, and learn by example.

Similarly, look at the print_paging_bar function, also from weblib.php.

Actually, for tables linked to SQL queries with paging, lib/tablelib.php is designed to handle exactly that case. However, I have never used it from scratch myself, I have only ever debugged code that was already using it successfully.
Average of ratings: -
In reply to Tim Hunt

Re: Messaging Report

by David Gray -

This is exactly the kind of suggestions I was after!

I initially used moodle/site:viewreports but for our organisation, thought "doanything" would be more approriate, but I'll change that

outputTable and doNav were a way to keep my code clean and free from repetition (this was the by-product of the early scripts, back when I connected to ADOdb by hand blush).

A lot of these functions, I was unaware of (because I didn't have the time to go source-hunting). When I DO get the time, I'm going to put together a cheat-sheet with some common functions in it. I missed one of those ;P

I was also going to put this in Contrib, but wanted some initial feedback first so that I didn't post it and open up obvious security holes (like I almost did with $_GET :P)

Thanks for the suggestions Tim :D

Average of ratings: -
In reply to David Gray

Re: Messaging Report

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
The best place to put any cheat-sheets you construct would at the other ends of the links at Developer_documentation#Core_components_that_affect_everything.

If you want to get fancy, I think that these days it may possible for admin reports to create a new capability just for themself (you need to create a db subfolder containging an access.php file) but that is probably overkill for this report.
Average of ratings: -