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

Duplicate date rows appear in statistics report

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 3.0.6, 3.1.2, 3.6, 3.7
    • Fix Version/s: 3.6.5, 3.7.1
    • Component/s: Reports
    • Testing Instructions:
      Hide
      Before the patch
      1. Uninstall your Moodle instance.
      2. Check out an older version of Moodle (e.g. "git checkout v3.5.0")
      3. Install your Moodle instance.
      4. Create some courses and users enrolled in those courses
      5. Log in as admin user
      6. Make sure site statistics are enabled (here is the docs page)
      7. Download and run the attached script "generate_stats.php" which will create some duplicate log entries to ensure that timeend matches (which is what causes this issue)
      8. Run cron to generate the stats, or execute the "\core\task\stats_cron_task" task:

        php admin/tool/task/cli/schedule_task.php --execute="\\core\\task\\stats_cron_task"

      9. Go to a user's profile (or your own profile)
      10. Under "Reports", click "Statistics"
      11. Check that you see rows with the same dates.
      12. Take note of the numbers in the Views. Posts, and All activity columns for these dates. (maybe take a screenshot for reference later)
      With the patch
      1. Check out the branch of the instance you're testing. (e.g. if you're testing for 3.6 "git checkout MOODLE_36_STABLE")
      2. Go to the upgrade
      3. Go back to your profile page and view your user statistics report.
      4. Confirm that you don't see the error "Did you remember to make the first column something unique in your call to get_records"
      5. Confirm you see only one entry per day in the table
      6. Confirm that the numbers for each date match the sum of the duplicated date rows from before. For example before the patch you see
        Period ending (day) Views Posts All activity
        12 June 2019 21 1 22
        12 June 2019 5 4 9

        You should now see

        Period ending (day) Views Posts All activity
        12 June 2019 26 5 31
      7. Confirm that the displayed graph matches the data on the table.
      Show
      Before the patch Uninstall your Moodle instance. Check out an older version of Moodle (e.g. " git checkout v3.5.0 ") Install your Moodle instance. Create some courses and users enrolled in those courses Log in as admin user Make sure site statistics are enabled (here is the docs page ) Download and run the attached script " generate_stats.php " which will create some duplicate log entries to ensure that timeend matches (which is what causes this issue) Run cron to generate the stats, or execute the " \core\task\stats_cron_task " task: php admin/tool/task/cli/schedule_task.php --execute="\\core\\task\\stats_cron_task" Go to a user's profile (or your own profile) Under " Reports ", click " Statistics " Check that you see rows with the same dates. Take note of the numbers in the Views. Posts, and All activity columns for these dates. (maybe take a screenshot for reference later) With the patch Check out the branch of the instance you're testing. (e.g. if you're testing for 3.6 " git checkout MOODLE_36_STABLE ") Go to the upgrade Go back to your profile page and view your user statistics report. Confirm that you don't see the error "Did you remember to make the first column something unique in your call to get_records" Confirm you see only one entry per day in the table Confirm that the numbers for each date match the sum of the duplicated date rows from before. For example before the patch you see Period ending (day) Views Posts All activity 12 June 2019 21 1 22 12 June 2019 5 4 9 You should now see Period ending (day) Views Posts All activity 12 June 2019 26 5 31 Confirm that the displayed graph matches the data on the table.
    • Affected Branches:
      MOODLE_30_STABLE, MOODLE_31_STABLE, MOODLE_36_STABLE, MOODLE_37_STABLE
    • Fixed Branches:
      MOODLE_36_STABLE, MOODLE_37_STABLE
    • Pull from Repository:
    • Pull 3.7 Branch:
    • Pull Master Branch:
      MDL-55997-master

      Description

      Since MDL-51913, when there is a duplicate row returned by the stats tables in report/stats/user.php, the resulting table will have a row for each of the duplicate entries.

      The list of stats returned by the database needs to be filtered to only have one entry per 'timeend' entry.

      This was previously done by stats_fix_zeros which would use the array key to do that, but now that the array key is the "id" field, it no longer does.

      Easiest solution is probably to build the $stats array in stats_fix_zeros by using $s->timeend rather than the array key $statid. But that may have consequences for other reports that use stats_fix_zeros.

      The alternative that fixes this specific regression without affecting other things is to filter the results right after performing the get_records_sql call.

        Attachments

        1. 1.png
          1.png
          81 kB
        2. 2.png
          2.png
          54 kB
        3. generate_stats.php
          5 kB
        4. image-2019-06-13-14-09-52-527.png
          image-2019-06-13-14-09-52-527.png
          108 kB

          Issue Links

            Activity

              People

              Assignee:
              peterdias Peter Dias
              Reporter:
              aolley Adam Olley
              Peer reviewer:
              Damyon Wiese
              Integrator:
              Jun Pataleta
              Tester:
              Janelle Barcega
              Participants:
              Component watchers:
              Adrian Greeve, Jake Dallimore, Mathew May, Mihail Geshoski, Peter Dias
              Votes:
              2 Vote for this issue
              Watchers:
              7 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                Fix Release Date:
                8/Jul/19

                  Time Tracking

                  Estimated:
                  Original Estimate - Not Specified
                  Not Specified
                  Remaining:
                  Remaining Estimate - 0 minutes
                  0m
                  Logged:
                  Time Spent - 1 day, 10 minutes
                  1d 10m