-
Bug
-
Resolution: Fixed
-
Minor
-
3.0.6, 3.1.2, 3.6, 3.7
-
MOODLE_30_STABLE, MOODLE_31_STABLE, MOODLE_36_STABLE, MOODLE_37_STABLE
-
MOODLE_36_STABLE, MOODLE_37_STABLE
-
MDL-55997-master -
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.
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.
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.
