Hi Jonathan,

Great document that shows the breadth of issues and the wide ranging impact any changes made will have.

I think we also need to take into account additional messaging methods that partners will be adding e.g. SMS which will require different message content.  Currently messages can be sent to Task block, Alert block, Popup notification, Email which can all contain the same text but if we needed to integrate into an SMS service we wouldn't be able to send the same text used in an email via an SMS.

I don't expect Totara to write an SMS integraton but any solution proposed requires an architecture that allows us to link to and define messages for other communication methods.

David

Hi Jonathan,

I think this is definitely heading in the right direction.  One area to also consider is more marketing style messaging, e.g. Trigger = time since last log-in.  We get a lot of requests for this.  

This may be inferred but what about Activity triggers. We've been exploring adding Completion Dates / Periods to Activities as an extension to Access Restriction for an Activity to support campaigns or spaced learning sequences, e.g. if I don't complete an activity in 10 days, I get a notification, the next activity is released 10 days after the previous one was released and I receive a notification.  

I'm working with a client who is requesting we create a full messaging system inside Totara. So they would be able to:

- Message users (one or multiple)

- Browse and add attachments to a message

- See a report of messages I've sent

- See when a user read a message

- See if a user deleted a message unread

- Re-send or forward a message previously sent

The document you posted talks about Totara components, but not about general messaging. In reality, this is recreating Outlook within Totara. Talking to our developer, it seems all the information is there, except Totara doesn't currently allow messaging to multiple users and adding attachments. For this use, the current Totara messaging UI won't work very well. 

Do you plan that this messaging rework would enable a more robust system to message between users, including any of these requirements?

Thanks much!

Susan

In addition to all of the above, it would be nice to have an HTML-editor available within every notification configuration. 

Hi Jonathan, I agree to the document. Digitizing of communication requires more control over what messages and alerts a system sending ...

You opened this discussion in December 2017. We are now in January 2019.

So, when will this be finalized? This is important to know for us because we are about to pay for a customization of the Learning Plan messaging and notifications capabilities.

This is something really urgent to fix and improve, as this component does strange things - it sends messages to manager even if the whole workflow denies any access to the plan or to any component. If you don't have a clear plan to improve the messaging. Administrators need to have full control over what messages are being sent according to the access rights defined in the workflow. And of course, the message itself needs to be customizable and allow for a nice UI design.

Many thanks for replying to this message and giving some more details on roadmaps.

As well as the suggestions that are made in the paper, and in the discussion, I'd like to underline a couple of features:

• Messaging at the course level with activity triggers etc. 
• Bulk emailing is often required on launch, when there are major changes to a system, etc. Integrations with third party bulk emailing services that are more suited to bulk emailing than Totara should be expected to be could be a considered. There are lots of things to think about e.g. some organisations won't want their user addresses to be stored in a 3rd party system, but these systems are properly designed to handle email scheduling, spam, the risk of being listed as a spammer (not a good look for an LMS!), and so on.
• I'd like to see granular control over who can and can't send and receive messages. An interesting recent use case is where a group of users are not permitted to send or receive email, SMS, or even internal messaging. This is very un-moodle, I know, but it's a legitimate use case.
• The solution needs good logging and reporting. Administrators want to know that the message was sent.