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

Improve performance for the self-conversation upgrading process

    XMLWordPrintable

    Details

    • Type: Task
    • Status: Closed
    • Priority: Critical
    • Resolution: Fixed
    • Affects Version/s: 3.7
    • Fix Version/s: 3.7
    • Component/s: Messages
    • Testing Instructions:
      Hide

      Prerequisite:

      1. Better use PHP 7.1 or 7.2 as far as those are the versions that are supported over all the versions involved in the testing instructions.
      2. Work with a git repository that is 100% updated (can do that by using git fetch --all --prune

      A. Setup for Moodle 3.4

      1. Install a Moodle 3.4.x site.
      2. Login as admin.
      3. Check that "Enable messaging system (messaging)" is enabled.
      4. Create 4 users: t1, s1, s2 and s3.
      5. From "Site administration > Users > Accounts > Bulk user actions", add all the users to the selection (including admin), choose "Send a message", write any text on the message body (for instance "This is a bulk message sent by the ADMIN"), click over the "Save changes" button and confirm you want to send the message to all these users.
      6. Create a course (C1).
      7. Enrol s1, s2 and s3 as students and t1 as editing teacher.
      8. Logout.
      9. Login as t1.
      10. Access to the C1 course's participants page.
      11. Select all the users (including t1), and in the "With selected users..." list choose "Send a message".
      12. Write a message (for instance "This is a bulk message sent by T1") and click over the "Send message to x people".
      13. Access to the messages page.
      14. CHECK t1 also appears in the list and his self-conversation contains the previous message.
      15. Send a couple of self-messages more to t1.
      16. Logout.
      17. Login as s2.
      18. Access to the messages page.
      19. Reply to admin message.
      20. Reply to t1 message.
      21. Search for s1 and send him a message.
      22. Search for s3 and send him a message.
      23. Logout.

      B. Upgrade to 3.6

      1. Upgrade the code from 3.4 to 3.6.
        1. run: git reset --hard origin/MOODLE_36_STABLE or git checkout MOODLE_36_STABLE or use mdk commands to switch to that branch.
        2. run php admin/cli/upgrade.php or use mdk commands to perform the upgrade.
      2. Login as admin.
      3. Execute the cron.
      4. CHECK the migrate_message_data task is executed (when the cron finishes, all the messages from admin, including the self ones, should be migrated to the new tables).
      5. Access to the messages page using the URL $CFG->wwwroot/message/index.php?id=2 (where 2 should be the admin id).
      6. CHECK admin self-conversation is not empty (it should contain the bulk message sent in step A.4).
      7. Send one self-message more to admin.
      8. CHECK the message can't be sent and a generalexceptionmessage is displayed.
      9. Logout.

      C. Upgrade to master

      1. Upgrade the code from 3.6. to master.
        1. run: git reset --hard origin/master or git checkout master or use mdk commands to switch to that branch.
        2. run php admin/cli/upgrade.php or use mdk commands to perform the upgrade.
      2. Click over the message icon to open the message drawer.
      3. CHECK the counter for the Starred section is 1.
      4. CHECK the self-conversation is displayed in the Starred section (it has been migrated using STEP 1 in the upgrade.php).
      5. Access to the self-conversation.
      6. CHECK the self-conversation contains the first bulk message sent using the "Bulk user actions".
      7. CHECK the self-conversation doesn't contain the message sent in step B.7 (because it hasn't been sent).
      8. Login as t1.
      9. Click over the message icon to open the message drawer.
      10. CHECK the counter for the Starred section is 1.
      11. CHECK the self-conversation is displayed in the Starred section (it has been migrated using STEP 2 in the upgrade.php).
      12. Access to the self-conversation.
      13. CHECK the self-conversation contains the second message sent from the course participants page and also the messages send directly by t1 from the messages page in the step A.14.
      14. Login as s1.
      15. Click over the message icon to open the message drawer.
      16. CHECK the counter for the Starred section is 1.
      17. CHECK the self-conversation is displayed in the Starred section.
      18. Access to the self-conversation.
      19. CHECK the self-conversation doesn't contain any message, only the explanation message should be displayed (it has been created on-demand).

      D. New user in master

      1. Login as admin.
      2. Create a new user (s4).
      3. Logout.
      4. Login as s4.
      5. Click over the message icon to open the message drawer.
      6. CHECK the counter for the Starred section is 1.
      7. CHECK the self-conversation is displayed in the Starred section.
      8. Access to the self-conversation.
      9. CHECK the self-conversation doesn't contain any message, only the explanation message should be displayed (it has been created on-demand).
      Show
      Prerequisite: Better use PHP 7.1 or 7.2 as far as those are the versions that are supported over all the versions involved in the testing instructions. Work with a git repository that is 100% updated (can do that by using git fetch --all --prune A. Setup for Moodle 3.4 Install a Moodle 3.4.x site. Login as admin. Check that "Enable messaging system (messaging)" is enabled. Create 4 users: t1, s1, s2 and s3. From "Site administration > Users > Accounts > Bulk user actions", add all the users to the selection (including admin), choose "Send a message", write any text on the message body (for instance " This is a bulk message sent by the ADMIN "), click over the "Save changes" button and confirm you want to send the message to all these users. Create a course (C1). Enrol s1, s2 and s3 as students and t1 as editing teacher. Logout. Login as t1. Access to the C1 course's participants page. Select all the users (including t1), and in the "With selected users..." list choose "Send a message". Write a message (for instance " This is a bulk message sent by T1 ") and click over the "Send message to x people". Access to the messages page. CHECK  t1 also appears in the list and his self-conversation contains the previous message. Send a couple of self-messages more to t1. Logout. Login as s2. Access to the messages page. Reply to admin message. Reply to t1 message. Search for s1 and send him a message. Search for s3 and send him a message. Logout. B. Upgrade to 3.6 Upgrade the code from 3.4 to 3.6. run: git reset --hard origin/MOODLE_36_STABLE or git checkout MOODLE_36_STABLE or use mdk commands to switch to that branch. run php admin/cli/upgrade.php or use mdk commands to perform the upgrade. Login as admin. Execute the cron. CHECK  the migrate_message_data task is executed (when the cron finishes, all the messages from admin, including the self ones, should be migrated to the new tables). Access to the messages page using the URL $CFG->wwwroot/message/index.php?id=2 (where 2 should be the admin id). CHECK  admin self-conversation is not empty (it should contain the bulk message sent in step A.4). Send one self-message more to admin. CHECK  the message can't be sent and a generalexceptionmessage is displayed. Logout. C. Upgrade to master Upgrade the code from 3.6. to master. run: git reset --hard origin/master or git checkout master or use mdk commands to switch to that branch. run php admin/cli/upgrade.php or use mdk commands to perform the upgrade. Click over the message icon to open the message drawer. CHECK the counter for the Starred section is 1. CHECK  the self-conversation is displayed in the Starred section (it has been migrated using STEP 1 in the upgrade.php). Access to the self-conversation. CHECK  the self-conversation contains the first bulk message sent using the "Bulk user actions". CHECK  the self-conversation doesn't contain the message sent in step B.7 (because it hasn't been sent). Login as t1. Click over the message icon to open the message drawer. CHECK the counter for the Starred section is 1. CHECK  the self-conversation is displayed in the Starred section (it has been migrated using STEP 2 in the upgrade.php). Access to the self-conversation. CHECK  the self-conversation contains the second message sent from the course participants page and also the messages send directly by t1 from the messages page in the step A.14. Login as s1. Click over the message icon to open the message drawer. CHECK the counter for the Starred section is 1. CHECK  the self-conversation is displayed in the Starred section. Access to the self-conversation. CHECK  the self-conversation doesn't contain any message, only the explanation message should be displayed (it has been created on-demand). D. New user in master Login as admin. Create a new user (s4). Logout. Login as s4. Click over the message icon to open the message drawer. CHECK the counter for the Starred section is 1. CHECK  the self-conversation is displayed in the Starred section. Access to the self-conversation. CHECK  the self-conversation doesn't contain any message, only the explanation message should be displayed (it has been created on-demand).
    • Affected Branches:
      MOODLE_37_STABLE
    • Fixed Branches:
      MOODLE_37_STABLE
    • Pull from Repository:
    • Pull Master Branch:
      MDL-65566-master-jake

      Description

      For sites with a huge number of users, the upgrading process to 3.7 may take a little bit longer because, for now, a lot of 1 by 1 inserts have to be done to create the self-conversations.

      Alternatives:

      a) Try to kill the 1by1 by some bulk operations.
      b) Try to delegate the creation to the adhoc task.
      c) Try to delegate the creation to on-demand (when the user directly accesses to the feature). This still requires a task filling the never-logged-in users.

      Problem with the use of ad-hoc tasks as part of the process is that they are not deterministic, especially if they are edited at any time. And, unless we have a way to detect the exact status of a user update... it can be really problematic, especially in the future, where we won't know if there are users still not migrated.

        Attachments

          Issue Links

            Activity

              People

              • Votes:
                2 Vote for this issue
                Watchers:
                7 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 day, 3 hours, 30 minutes
                  1d 3h 30m