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

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

    XMLWordPrintable

    Details

    • Testing Instructions:
      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.
    • Affected Branches:
      MOODLE_36_STABLE
    • Fixed Branches:
      MOODLE_37_STABLE
    • Pull from Repository:
    • Pull Master Branch:
      MDL-64017_master

      Description

      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.

        Attachments

          Issue Links

            Activity

              People

              • Votes:
                0 Vote for this issue
                Watchers:
                11 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved:
                  Fix Release Date:
                  20/May/19

                  Time Tracking

                  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