09 October 2013, 20:28

Hello,

we're working on another plugin to extend the message feature. First task was an outbox-page which gives you access to the messages you have sent yourself by just accessing the messages from table notification_internal_activity but we realized that it is strange when messages vanish from your outbox once the recipient deletes them and on the other hand you can't delete messages from your outbox because otherwise they would disappear from the inbox of the recipient as well. 

Another target are messages to multiple recipients, With the outbox-view we skipped the idea of just sending a bunch of single messages to each recipient. So we endet up creating our own message table with a second table for the message-user-relation. 

What I'm not sure about is how to change the number of unread messages in the right top of the page, next to the envelope-icon. I realized that the User::add_unread()-method accepts negative values, so I could count the messages (in the new table) and add them (minus the recent/outdated unread-messag-count) each time, the menu_items-function is called, but that's a lot of database-queries whereas now the unread-message-count is stored in the session. 

From what I've seen, the message-count is only maintained by the database-triggers introduced in notification/internal/lib.php attached to notification_internal_activity, so I guess I could add database-triggers to the newly introduced tables. Would that work or does anyone have any better idea to solve that issue? 

I'm not sure about what plans you have for the message system of mahara but if you're interested in integrating the feature into mahara, we'd happily share it. For the moment I get along without touching the core-code but only if I leave all system messages to the old notification-system and have the new inbox display a mixture of both message systems. But I guess it would be nice to replace the old notification-system completely - and get rid of the redirects for inbox and sendmessage.php

15 October 2013, 17:48

Hello Tobias,

This would be a feature of interest to other users, for example see https://bugs.launchpad.net/bugs/1202706

Howe do you plan to implement it? Will everyone be able to contact multiple users or is that restricted to staff and admin and a normal user's friends, members of a group?

Cheers

Kristina

16 October 2013, 3:29

Hi Kristina,

thanks for the input. Everybody will be able to send messages to multiple users, restricted as before to those users, he can now send usual notifications to (I think you can forbid non-friended users to send you messages, that restriction won't fall). For the moment, you have to select each user in a autocomplete-field, so we don't expect massive Spam. Also there will be a reply-all button if you are among other recipients of a message you want to reply to. So one of the scenarios we thought about was a discussion amongst a small set of people, but not necessarily a mahara-group. 

All system messages are sent from without the core code and I can't change that without touching the mahara core, so for now, the inbox and outbox will show the former notifications as well. (But the reply-function will be disabled for old user-ti-user-messages). Only the sendmessage-php is replaced so user-to-user-messages will all be sent via the new message-system. 

On implementation level, these new messages are stored in a different table with the sender- and receiver-relation stored in a second table. So

• when a receiver (or all receivers) of a message delete it but the sender doesn't, it still appears in his outbox (and vice versa)
• your message-thread won't break just because someone else deletes a messages from his inbox that was up the message thread
• when you send a message to more than one user, there still will only be one message in your outbox

The suggested feature from the linked launchpad-entry to send messages to a complete group or even all users makes sense as well. It would be easy to integrate groups (of a user) or all users (probably only for administrators) using something like a shortcut, but the users would all appear in the recipient list. Let me think about the idea to add groups as a recipient - like a fixed list. 

One thing that still bugs me about the message-count: I was able to use the database-triggers to modify the message-count for all users. But should you later remove the plugin from the installation with unread messages, the message-count might be broken and you would have to fix that directly on the database-level. On the other hand, there is no mechanism to deinstall plugins in Mahara so far anyway... 

16 October 2013, 7:49

Hello Tobias,

Thank you for the additional information. I'm afraid I can't help with your message count question.

For people being able to send message to everyone who allows being sent a message to, I am very afraid that this can be misused. Yes, it is possible to do that now already by manually sending messages and some spammers have already misused that functionality here on mahara.org. Also some crafty students on multi-tenanted Mahara instances can suddenly email tons of people. Some already invite lots, and I'm not talking about 50 or 100, but thousands of people into their groups and do that very diligently by adding 100 people at a time. Very crafty students who test the boundaries...

If you have auto-completion, I imagine that all you need to do is start typing a name and suggestions pop up. You'll easily be able to thus spam lots of users... That's why I was asking if this could be restricted. For group recommendations / friend invitations we restricted it so that regular users can only invite their friends / recommend the group to their friends, but not to everyone.

I could imagine a similar thing here because why would you want to send a mass email to people? I think it would be for the following reasons primarily:

• send a message to all your friends because "friends" is a group without discussion forums and thus no way to send messages to
• send a message to all group members
• send a message by a staff / admin to all institution members
• send a message to all users by the site admin to make them aware of a change in policy / important outage etc.

Social networking sites don't let you send messages to everyone in their network in bulk only because people said they can be contacted unless I'm wrong. That would be quite a privacy issue because bulk messages can be misused very much. Moodle also doesn't allow a user to send messages to everyone, not even in a course unless you are a teacher.

I just want to open the discussion about this because I know that some countries have strict privacy laws and also if you have students of various grade levels on one platform, you may need to be careful. It can also be used for mass marketing / spamming and that would destroy the confidence of users in the system.

I hope others will chime in in this discussion so we can nut it out.

Cheers

Kristina

16 October 2013, 19:49

Hi Kristina,

I understand your concern about mass spam mails and I have to admit that we haven't given that problem that much thought in our context because we deal with a smaller and - presumably - more responsible set of users. 

I still don't think the autocomplete field invites to sent a mail to a 100 people or more as you can always only add a single user. So for every invited user you have to make at least two mouse clicks and press one key. On the other hand it would be really easy to restrict the names in the autocomplete-set to friends, maybe with an option to activate or deactivate this restriction. 

When designing the plugin we rather thought about small sets of people that want to communicate, independently of group-borders or institutions. Independently in particular meaning a smaller subset, like three or four people. If you do mass notifications on the other hand as for a change of policy or maintenance outages or something the like you wouldn't want the user to see all the other recipients, especially not with a "reply-all" button.Unless the set of users appears as one meta-recipient and you forbid non-privileged users to send a message to a set like that. 

Two more things we had in mind when planing the plugin: first we liked the conversation history that shows up when you reply to a message. I think this is not a very common feature in social networks - and kind of complicates matters if you work on an independent outbox for example. Second, if you communicate with a set of people it would be nice not to spam your outbox with a single message per recipient. And of course the reply-all functionality, still thinking in the conversation-setup. 

I think we had different setups in mind but it would be interesting to see if we can bring them togegher in one plugin. 

For that matter: is there a way to manipulate settings for a plugin? 

16 October 2013, 21:09

Hello Tobias,

I get where you are coming from, and I think that the majority of users are responsible. However, there are always a few, and for a core featuer we do need to try to keep these edge cases in mind and discuss them to find a way to mitigate potential problems. ;-)

For my use case of site amin sending a message to everyone / all institution admins / all staff, I did not mean that the recipients should be displayed or that a "reply all" functionality would be available. That would definitely not be a good thing. In Mahara, we usually deal with notifications that can be sent on via email, but we don't email people directly. Users can decide whether to receive their notifications in their inbox or via email as well. I don't know if that would make certain things easier or not. At the moment, when you receive emails, they aren't sent from a person's account, but always from the standard email address. However, a user's name shows up as sender. That is something that has been confusing some people because they hit "Reply" and expect the mail to go to that person.

Anyway... I don't know what the best way is to manipulate behavior of who can send what. So far, we do pretty much all of that via the roles and institution settings. For example, if you are a staff member, you have certain privileges. And depending on your institution's settings, eventually you could have more permissions. So far, all additional staff access though is controlled on the site level, e.g. staff access to statistics and to user reports which are normally only available to admins. There are no individual institution settings yet. But we try to implement as many settings on the institution level as possible to make the use of Mahara more flexible if you want / need to work with multiple institutions. Even within one organization, differentiating into institutions can be useful, e.g. to give students different settings than teachers.

Cheers

Kristina

17 October 2013, 4:04

Hi Kristina,

we won't change the delivery-behavior, the system still respects the notification-settings and sends mails additionaly to the notifications, if users choose that option. 

I think, I'll upload the plugin via Gerrit when we have a working version and then you can have a look at it. 

21 October 2013, 15:45

Hello Tobias,

Sounds great. :-) It's also good that you and Angela are talking at https://mahara.org/interaction/forum/topic.php?id=5798

Cheers

Kristina

06 November 2013, 2:38

Hi Kristina,

I uploaded into gerrit more or less what we did to the message system (subject: New plugin as user-message system to multiple recipients): A plugin that redirects the calls to the inbox and to sendmessage.php. I think if you would integrate it into the core, it would make sense to replace the complete message system, which would make the inbox (and outbox) a bit easier. 

For now, it's only a plugin, which makes it easier for us to maintain when we upgrade our mahara installation. Still the message count might affected by every mail recieved, so I wouldn't recommend installing the plugin into a productive system until you are sure you want to use it. 

The users you can select are restricted to friends, so far. It wouldn't be that difficult to add users that share a group though. 

Lookin forward to your comments