Open weilai-irl opened 2 months ago
@weilai-irl I note your patch here reverts: https://github.com/catalyst/moodle-mod_reengagement/commit/d358026f7b37bb99f6f7977f5289039d54d417cb but there's also a decent chunk to review here so it might sit for a while until we get a chance to review it properly!
thanks for the PR!
Hi @danmarsden
I have made changes to add back the missing commit and and address the issues found in the checks. Please feel free to run the checks again to see if all pass.
Regards, Lai
Hi Catalyst team,
We recent made some changes to the plugin with the main aim to improve the performance of the scheduled task.
The performance issue The performance issue was raised from a Moodle site that we maintain, which have about 30 mod_reengagement activities in different courses, many of which are legacy courses that have been hidden, or moved to hidden course categories. Each run of the scheduled task now takes over 15 minutes to run, and the logic to mark completion and send emails are only reached after the logic to create in-progress records, at the end of the scheduled task. On some courses, mod_reengagement activities are used to allow users to access subsequent activities following a delay after another activity is completed, and the duration is set to be relatively short period, e.g. 30 minutes or 1 hour. Long scheduled task running time effectively adds a lot of extra time to the configured duration, resulting in confusion to users.
The solution We have made two changes to improve this:
nextruntime
of the expected completion time / email time, so will be triggered by the Moodle cronjob separate from the scheduled task.Bug fix in completion time / email time display This is related to issue #151. When a student access the plugin view.php page, the completion time / email time displayed is fetched by finding a random in progress record of the user, without limiting the in-progress record to the current mod_reengagement activity only. The pull request contains the fix to this issue.
Other changes The PR also contains a small change to add an option to reset data belonging to the mod_reengagement plugin when the course is reset. I noticed that the reset function was actually implemented, but the option didn't exist, so the function would never be triggered.
Please review the changes, and let me know if you have any questions.
Regards, Lai