Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-64017

Provide a means for message processors to identify and handle group messages

XMLWordPrintable

    • MOODLE_36_STABLE
    • MOODLE_37_STABLE
    • MDL-64017_master
    • Hide
      Prerequisites.
      1. Set-up mailcatcher (https://mailcatcher.me/).
      2. Log in as an admin.
      3. Visit ‘Site administration’ > ‘Server’ > ‘Outgoing mail configuration’.
      4. Set the 'SMTP hosts' field to '127.0.0.1:1025' and save.
      5. Visit http://127.0.0.1:1080/ in your browser so you can view outgoing emails.
      6. Create a course.
      7. Enrol 4 users as students (A, B, C and D).
      8. Create a group with 'Group messaging' to 'Yes'.
      9. Assign all the users you enrolled into that group.
      Test 1
      1. Log in as B.
      2. Send 5 messages to the group.
      3. Log in as C.
      4. Send 5 messages to the group.
      5. Log in as D.
      6. Send 5 messages to the group.
      7. Log in as B.
      8. Send 1 message to the group.
      9. Log in as C.
      10. Send 1 message to the group.
      11. Log in as D.
      12. Send 1 message to the group.
      13. Log out
      14. Run cron:

        php admin/tool/task/cli/schedule_task.php --execute="\message_email\task\send_email_task"
        

      15. Confirm A gets an email saying there are 18 unread messages.
      16. Confirm the email contains the last 3 messages belonging to that group.
      17. Confirm when clicking the link and logging in as A you are redirected to the conversation.
      18. Run cron:

        php admin/tool/task/cli/schedule_task.php --execute="\message_email\task\send_email_task"
        

      19. Confirm no more emails are sent.
      Show
      Prerequisites. Set-up mailcatcher ( https://mailcatcher.me/ ). Log in as an admin. Visit ‘Site administration’ > ‘Server’ > ‘Outgoing mail configuration’. Set the 'SMTP hosts' field to '127.0.0.1:1025' and save. Visit http://127.0.0.1:1080/ in your browser so you can view outgoing emails. Create a course. Enrol 4 users as students (A, B, C and D). Create a group with 'Group messaging' to 'Yes'. Assign all the users you enrolled into that group. Test 1 Log in as B. Send 5 messages to the group. Log in as C. Send 5 messages to the group. Log in as D. Send 5 messages to the group. Log in as B. Send 1 message to the group. Log in as C. Send 1 message to the group. Log in as D. Send 1 message to the group. Log out Run cron: php admin/tool/task/cli/schedule_task.php --execute="\message_email\task\send_email_task" Confirm A gets an email saying there are 18 unread messages. Confirm the email contains the last 3 messages belonging to that group. Confirm when clicking the link and logging in as A you are redirected to the conversation. Run cron: php admin/tool/task/cli/schedule_task.php --execute="\message_email\task\send_email_task" Confirm no more emails are sent.

      As discussed on MDL-63283, we'd like a formal way for processors to be allowed to opt in to processing of (or be made aware of) messages sent to group conversations.

      Currently, as per MDL-63283, no processors are called at all when this type of message is sent. This is excluded, based on conversation type, in the message/manager, and was done to avoid huge numbers of emails, sms, etc being sent out to all recipients in a group conversation every time a single message is sent.

      Ideally, we'd want a way for processors to be aware of the type of the conversation to which the message is being sent, and make their own decisions based on that. At the moment, processors can only see the convid in the eventdata, and would then need to check the conversation type and make assertions based on that.

      Some ideas we threw around just now were:

      • new message provider in lib/db/messages (might be a lot of work as instantmessage is referenced a fair bit and it's state on/off is tied to the state of the messaging feature itself)
      • admin config for message processors, allowing admins to specify whether or not a given processor handles messages to groups.

      We'd need to update the core outputs too as part of this work.

            markn Mark Nelson
            jaked Jake Dallimore
            Carlos Escobedo Carlos Escobedo
            Adrian Greeve Adrian Greeve
            Shamim Rezaie Shamim Rezaie
            Votes:
            0 Vote for this issue
            Watchers:
            11 Start watching this issue

              Created:
              Updated:
              Resolved:

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 1 week, 3 days, 2 hours
                1w 3d 2h

                  Error rendering 'clockify-timesheets-time-tracking-reports:timer-sidebar'. Please contact your Jira administrators.