Messaging: Messaging system in 2.0. Proposed changes

Messaging: Messaging system in 2.0. Proposed changes

by Tim Hunt -
Number of replies: 25
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

The new messaging system is based on the idea that the user should be able to control which of the messages they receive go through with route. (If you are not familiar with this, in your Moodle 2.0 test install, go to your profile, then click on the messaging link in the settings block.

That is OK, so far as it goes, but there are some situations where the admin legitimately needs some control. Here are the two scenarios I have in mind:

A. According to instituational policy, notification of quiz submissions need to be sent through a custom messaging system that integrates with the student portal and logs all messages, so it can be verified that a students have been sent the "you have successfully completed your quiz" email.

B. The institution has signed up an SMS service, so that students can receive some notifications on their mobile. However, this service has a cost attached, so users should never be allowed to ask for forum notifications, or other high-volume things, to be sent over SMS.

I think that these are both reasonable requirements. My proposal for how to implement them is:

1. Create a new bit in the admin menu: Admin -> Plugins -> Notification methods -> Manage notification methods. (Why does this not exist already?)

2. Once that exists, move the settings that are currently on Admin -> Server -> Email and Admin -> Server -> Jabber, to Admin -> Plugins-> Notification methods -> Email and Admin -> Plugins-> Notification methods -> Jabber. (This is not strictly necessary, but seems logical.)

3. The Manage notification methods page should be a big grid, laid out the same as as the messaging settings in the user profile. That is, there is a list of message types down the side, and Notification methods across the top. Inside each cell of the grid the grid, instead of a checkbox, there should be chice of 4 options: Not allowed / Allowed, off by default / Allowed, on by default / Always used.

4. The messaging settings page in a user's profile must be updated to behave appropriately when the admin has set some combinations to Not allowed or Always used.

5. The messaging library must be updated to ensure that the admin settings are always enforced.

6. Extend the format for .../db/messages.php files in each plugin, so that the plugin can set defaults for the admin settings described in 3. above. (Not sure if this is necessary. If it is done, it must be done in a backwards-compatible way.)

Does this seem sensible? If we do this, would it be accepted into Moodle 2.1?

Average of ratings: Useful (3)
In reply to Tim Hunt

Re: Messaging: Messaging system in 2.0. Proposed changes

by David Mudrák -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers Picture of Plugins guardians Picture of Testers Picture of Translators
I like the proposal Tim! Together with this, we might consider if it is worthy to have some in-built logging system for the messaging. Situations when a student claims they had not received this or that notification are pretty common. Not sure if the standard logging facilities would be suitable for this though.

Thanks for this promising design.
Average of ratings: -
In reply to David Mudrák

Re: Messaging: Messaging system in 2.0. Proposed changes

by Andrew Davis -

I think we're already logging messages being sent although I could be wrong...

Average of ratings: -
In reply to Tim Hunt

Re: Messaging: Messaging system in 2.0. Proposed changes

by Sam Hemelryk -

Hi Tim,

I'm no expert on the messaging system but certainly what you are purposing seems very sensible and would be welcome in 2.1 (although of course I can't make that call)

I'm not too sure how well the Always used option would work
I can see how it would be great if it worked, and for messaging systems where the details of where the message is going to is either a required field (email) or has some sort of default I couldn't see any problems, but having that option for systems that users may not have entered destination information like Jabber that setting may lead to real confusion?
I think this is what you are getting at in point 4 I guess I am just lacking to see how that could be done in such as way that it was always clear as too who exactly got the message.

Cheers

Sam

Average of ratings: -
In reply to Sam Hemelryk

Re: Messaging: Messaging system in 2.0. Proposed changes

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

Ah well, at the moment, the messaging options in the user profile allow the student to select the Jabber option, even if the admin has not set it up. Clearly that needs to be fixed too. Add:

7. On Admin -> Plugins -> Notification methods -> Manage notification methods. The admin should be able to enable/disable any method entirely. If a method requires configuration to work (e.g. Jabber) the admin should not be able to enable it for users until they have provided the necessary settings. (And user profile settings page needs to be updated to cope with this.)

In fact, it might be better if Manage notification methods is where admins enable and disable different methods, and there is a separate page Default notification methods to handle 1./3. above.

Average of ratings: -
In reply to Tim Hunt

Re: Messaging: Messaging system in 2.0. Proposed changes

by Sam Hemelryk -

Hehe yes several things that can be improved... good on you for tackling it! :D

Having two separate pages, one to enable/disable messaging plugins, and the other to set the default notification method is an interesting idea.

Thinking over it for a while I do like the two separate pages more, it's more in tune with existing plugin management areas, and less scary than one monster table of enable/disable madness.

Average of ratings: -
In reply to Tim Hunt

Re: Messaging: Messaging system in 2.0. Proposed changes

by Jenny Gray -

This all sounds really good to me too.  The only bit that concerns me is that if the user has to enter their own id (jabber, email address, whatever) for the messaging system to work, then this field on the user profile needs to be come a required field.  Email already is, but jabber isn't.

We can't let it get into a situation where admin says "jabber is configured, and this message always go by jabber", but the user doesn't have a jabberid in the database.

Average of ratings: -
In reply to Jenny Gray

Re: Messaging: Messaging system in 2.0. Proposed changes

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

OK, so like the way that the admin page only lets the admin enable the Jabber plugin after they have configured it correctly, the user-profile page, and back-end library code needs to check that users have a jabber id configured before allowing them to choose to receive messages via Jabber.

Both of these features probably require new callbacks into each messaging plugin. See message/output/lib.php. I suggest adding

public abstract function is_system_configured();
public abstract function is_user_configured($user);

both returning boolean.

Oh, I see that the private method message_output_jabber::_jabber_configured already exists.

Average of ratings: -
In reply to Tim Hunt

Re: Messaging: Messaging system in 2.0. Proposed changes

by Andrew Davis -

Tim, just to check I understanding what you're proposing, you want to allow admins to configure a subset of messages processors that will be available to users for each message type. Is that correct?

Average of ratings: -
In reply to Andrew Davis

Re: Messaging: Messaging system in 2.0. Proposed changes

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

Yes, that is the one-sentence summary.

Average of ratings: -
In reply to Tim Hunt

Re: Messaging: Messaging system in 2.0. Proposed changes

by sam marshall -
Picture of Core developers Picture of Peer reviewers Picture of Plugin developers

Looks good (or possibly the revised one).

By the way, what I'm about to say isn't actually what Tim is aiming for (he's looking at the secured-email system for quiz notifications that he mentioned), but I think we would probably want to use these features to 'lock down' the options so that it always uses email (or the secure-notification system) and doesn't let users choose - at least in our initial Moodle 2 deployment.

Allowing a variety of options would add to an already very difficult support task - we get a lot of queries along the lines of 'the system didn't send me this email' (in all cases I've ever looked into except one, it totally did, but the problem is it takes time to look into it, and you have to because there's always that 'one' case where there was a bug somewhere).

So user choice for notifications is the sort of option we would prefer to enable, carefully, at a later date. Not sure if other institutions have this kind of support issue.

--sam

Average of ratings: -
In reply to Tim Hunt

Re: Messaging: Messaging system in 2.0. Proposed changes

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

Just an update that we (the OU) have now contracted LUNS (https://www.luns.net.uk/services/virtual-learning-environments/) to implement this spec for us. They have done other development work for us in the past, and hopefully this will work out as well as that did.

Average of ratings: -
In reply to Tim Hunt

Re: Messaging: Messaging system in 2.0. Proposed changes

by Dan Poltawski -
Thanks Tim.

Just a note - the issue for this improvement is: MDL-27171 (and we'll be updating with progress on there)

Average of ratings: -
In reply to Tim Hunt

This forum post has been removed

The content of this forum post has been removed and can no longer be accessed.
In reply to Deleted user

Re: Messaging: Messaging system in 2.0. Proposed changes

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

Dan and I were looking at this yesterday, and as far as we can make out from the code, at the moment, the default settings for a particular user are set up the first time Moodle tries to send them a message. That is rather odd, and leads to the symptoms you observe, if you go and look at the message settings in your profile before Moodle has send you a message.

Average of ratings: -
In reply to Tim Hunt

Re: Messaging: Messaging system in 2.0. Proposed changes

by Howard Miller -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
I hope that somewhere along the line the end user UI for messaging gets tidied up. It's currently both annoying (e.g. opt-out popups... Grrrr) and the interface is counter-intuitive (relies on clicking the right mystery icon to see the messages).

Can we also have a select-all-and-delete please smile

It would be a lot more useful with a little thought and/or user testing of the interface.
Average of ratings: Useful (1)
In reply to Howard Miller

Re: Messaging: Messaging system in 2.0. Proposed changes

by Frank Ralf -
Subscribing (see "Ignore messages" ignored)

Frank
Average of ratings: -
In reply to Frank Ralf

Re: Messaging: Messaging system in 2.0. Proposed changes

by Dan Poltawski -
We'll see if we can find some time to look at improving this after the rest of the improvements are completed.

If anyone wants to fund that work, we will certainly have time to look at it..
Average of ratings: -
In reply to Dan Poltawski

Re: Messaging: Messaging system in 2.0. Proposed changes

by Howard Miller -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
It's a shame that (again) the backend stuff seems to be more important (more interesting?) than than a good user interface. It'll end in tears wink
Average of ratings: -
In reply to Howard Miller

Re: Messaging: Messaging system in 2.0. Proposed changes

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

Well, this back-end stuff happened to be very important to the OU, so we paid to get it fixed. That is the open-source, scratch-your-own-itch thing in action.

Open source development is not a zero-sum game. If we had not spent this money on the back-end, we would not have transferred it to the developing the UI. We don't use the messaging UI. We just want some control over where forum subscription emails, and quiz submission emails go.

Average of ratings: -
In reply to Tim Hunt

Re: Messaging: Messaging system in 2.0. Proposed changes

by Howard Miller -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Hi Tim,

And, no doubt, a very good thing too. I understand your position completely but it doesn't make the overall situation with messaging any less frustrating.

Of course, I'd put my time/money where my mouth is but there are higher priorities (as always)
Average of ratings: -
In reply to Howard Miller

Re: Messaging: Messaging system in 2.0. Proposed changes

by Florian Schneider -

Actually, there is a plugin for moodle 1.9 improving the user experience (see http://moodle.org/mod/forum/discuss.php?d=137041). Maybe this codebase could be a good starting point for improving the frontend in Moodle 2.x?

Unfortunately my own skills in programming php & sql are not good enough to port this patch to Moodle2. mixed

Average of ratings: -
In reply to Tim Hunt

Re: Messaging: Messaging system in 2.0. Proposed changes

by Dan Poltawski -
Hi Everyone,

Just a note to say that this work has now been integrated into Moodle 2.1. smile

As Helen says in her post, it'd be great to have as many people testing these changes as possible to make Moodle 2.1 a great release.

It'd actually be a great time to report bugs in the Moodle 2.0+ messaging framework since we're now intimately familiar with at LUNS and might be able to fix bugs reported v.quickly. wink

Dan
Average of ratings: -
In reply to Dan Poltawski

Re: Messaging: Messaging system in 2.0. Proposed changes

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

Perhaps it is now safe to admit Something: When we sent this specification out to several contractors at the end of April, saying "Do you want to bid on this, to get it done in time to include in Moodle 2.1?" I was half expecting everyone to come back and say "Don't be silly, that's impossible."

Fortunately, Dan/LUNS thought they could do it, and they were right. I am impressed!

Average of ratings: -