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

tool_moodlenet: Upgrade to clean user profile is slow, pointless

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Minor Minor
    • 4.0.5
    • 4.0.4
    • MoodleNet
    • MOODLE_400_STABLE
    • MOODLE_400_STABLE
    • MDL-75738-master
    • Hide

      This test just runs the upgrade steps and confirms that the 'dangerous' html is still removed.

      Note: At step 3 you need to run some SQL because the UI should not actually let you set dangerous values into this field any more.

      1 Install a disposable Moodle 3.11 test system
      2 Create a test user account and make a note of the id.
      3 Using a database administration tool, run this SQL, replacing 12345 with the actual user id and prefix_ with your actual prefix (usually mdl_):

      UPDATE prefix_user SET moodlenetprofile='X<script>alert("Hackerman")</script>Y' WHERE id=12345;
      

      4 Upgrade the server to Moodle 4.x (version being tested)
      5 In the database, do

      SELECT moodlenetprofile FROM prefix_user WHERE id=12345;
      

      EXPECTED: The value should be an empty string (not 'XY' as you might expect, because rather than just being cleaned, all values in this field are set to blank).

      Show
      This test just runs the upgrade steps and confirms that the 'dangerous' html is still removed. Note: At step 3 you need to run some SQL because the UI should not actually let you set dangerous values into this field any more. 1 Install a disposable Moodle 3.11 test system 2 Create a test user account and make a note of the id. 3 Using a database administration tool, run this SQL, replacing 12345 with the actual user id and prefix_ with your actual prefix (usually mdl_): UPDATE prefix_user SET moodlenetprofile='X<script>alert("Hackerman")</script>Y' WHERE id=12345; 4 Upgrade the server to Moodle 4.x (version being tested) 5 In the database, do SELECT moodlenetprofile FROM prefix_user WHERE id=12345; EXPECTED: The value should be an empty string (not 'XY' as you might expect, because rather than just being cleaned, all values in this field are set to blank).

      We are investigating poor performance of the update to Moodle 4.0 on our systems. One point is the tool_moodlenet upgrade 2021052501. This was applied in MDL-69240 to version 3.9, 3.10, but it still runs (again, presumably) on a Moodle 4.0 (from 3.11) upgrade because the version code in Moodle 3.11.8 is 2021051701. (Running it again should not do any harm, except for the performance cost, so this is OK.)

      This upgrade contains the following SQL:

              $sql = "SELECT u.*
                        FROM {user} u
                       WHERE u.moodlenetprofile IS NOT NULL";
      

      Then it loops through the users, makes a change to moodlenetprofile and calls update_record.

      There are 2 things wrong with this update:

      1. As it selects all the user fields, it will update all fields of the record, when it only needs to update one.

      but more fundamentally for us

      2. We have about a million users where moodlenetprofile is NULL, but we also have 32,000 where it's an empty string.

      We don't use moodlenet so this upgrade should be doing nothing; instead it's updating all fields of 32,000 user records one at a time, which takes a while.

      Also 3. It should not do update_record if the clean_text didn't do anything.

      HOWEVER all these performance details are pointless because there is now an admin step further down (2022021601) which (much more efficiently) sets the field to blank for all users anyway. So I propose just deleting the step, there is no point cleaning something we are about to blank.

        1. MDL-75738_master.png
          18 kB
          John Edward Pedregosa
        2. MDL-75738_v400.png
          13 kB
          John Edward Pedregosa

            quen Sam Marshall
            quen Sam Marshall
            Katie Ransom Katie Ransom
            Andrew Lyons Andrew Lyons
            John Edward Pedregosa John Edward Pedregosa
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved:

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 1 hour, 30 minutes
                1h 30m

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