Messaging: Messaging system in 2.0. Proposed changes

Messaging: Messaging system in 2.0. Proposed changes

por Tim Hunt -
Número de respostas: 25
Foto de Core developers Foto de Documentation writers Foto de Particularly helpful Moodlers Foto de Peer reviewers Foto de 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?

Em resposta a 'Tim Hunt'

Re: Messaging: Messaging system in 2.0. Proposed changes

por David Mudrák -
Foto de Core developers Foto de Documentation writers Foto de Moodle HQ Foto de Particularly helpful Moodlers Foto de Peer reviewers Foto de Plugin developers Foto de Plugins guardians Foto de Testers Foto de 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.
Em resposta a 'Tim Hunt'

Re: Messaging: Messaging system in 2.0. Proposed changes

por 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

Em resposta a 'Sam Hemelryk'

Re: Messaging: Messaging system in 2.0. Proposed changes

por Tim Hunt -
Foto de Core developers Foto de Documentation writers Foto de Particularly helpful Moodlers Foto de Peer reviewers Foto de 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.

Em resposta a 'Tim Hunt'

Re: Messaging: Messaging system in 2.0. Proposed changes

por 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.

Em resposta a 'Tim Hunt'

Re: Messaging: Messaging system in 2.0. Proposed changes

por 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.

Em resposta a 'Jenny Gray'

Re: Messaging: Messaging system in 2.0. Proposed changes

por Tim Hunt -
Foto de Core developers Foto de Documentation writers Foto de Particularly helpful Moodlers Foto de Peer reviewers Foto de 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.

Em resposta a 'Tim Hunt'

Re: Messaging: Messaging system in 2.0. Proposed changes

por 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?

Em resposta a 'Tim Hunt'

Re: Messaging: Messaging system in 2.0. Proposed changes

por sam marshall -
Foto de Core developers Foto de Peer reviewers Foto de 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

Em resposta a 'Tim Hunt'

Re: Messaging: Messaging system in 2.0. Proposed changes

por Tim Hunt -
Foto de Core developers Foto de Documentation writers Foto de Particularly helpful Moodlers Foto de Peer reviewers Foto de 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.

Em resposta a 'Tim Hunt'

Re: Messaging: Messaging system in 2.0. Proposed changes

por Dan Poltawski -
Thanks Tim.

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

Em resposta a 'Tim Hunt'

Este tópico do fórum foi eliminado

O conteúdo deste tópico do fórum foi removido e não pode voltar a ser acedido.
Em resposta a 'Utilizador apagado'

Re: Messaging: Messaging system in 2.0. Proposed changes

por Tim Hunt -
Foto de Core developers Foto de Documentation writers Foto de Particularly helpful Moodlers Foto de Peer reviewers Foto de 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.

Em resposta a 'Tim Hunt'

Re: Messaging: Messaging system in 2.0. Proposed changes

por Howard Miller -
Foto de Core developers Foto de Documentation writers Foto de Particularly helpful Moodlers Foto de Peer reviewers Foto de 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 sorriso

It would be a lot more useful with a little thought and/or user testing of the interface.
Em resposta a 'Howard Miller'

Re: Messaging: Messaging system in 2.0. Proposed changes

por Frank Ralf -
Em resposta a 'Frank Ralf'

Re: Messaging: Messaging system in 2.0. Proposed changes

por 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..
Em resposta a 'Dan Poltawski'

Re: Messaging: Messaging system in 2.0. Proposed changes

por Howard Miller -
Foto de Core developers Foto de Documentation writers Foto de Particularly helpful Moodlers Foto de Peer reviewers Foto de 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 piscar o olho
Em resposta a 'Howard Miller'

Re: Messaging: Messaging system in 2.0. Proposed changes

por Tim Hunt -
Foto de Core developers Foto de Documentation writers Foto de Particularly helpful Moodlers Foto de Peer reviewers Foto de 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.

Em resposta a 'Tim Hunt'

Re: Messaging: Messaging system in 2.0. Proposed changes

por Howard Miller -
Foto de Core developers Foto de Documentation writers Foto de Particularly helpful Moodlers Foto de Peer reviewers Foto de 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)
Em resposta a 'Howard Miller'

Re: Messaging: Messaging system in 2.0. Proposed changes

por 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. confuso

Em resposta a 'Tim Hunt'

Re: Messaging: Messaging system in 2.0. Proposed changes

por Dan Poltawski -
Hi Everyone,

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

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. piscar o olho

Dan
Em resposta a 'Dan Poltawski'

Re: Messaging: Messaging system in 2.0. Proposed changes

por Tim Hunt -
Foto de Core developers Foto de Documentation writers Foto de Particularly helpful Moodlers Foto de Peer reviewers Foto de 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!