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

Suspended meta-course enrolments generate LOTS of logs by always doing (un)enrolments

    XMLWordPrintable

    Details

    • Database:
      MySQL
    • Testing Instructions:
      Hide
      1. Login as an admin
      2. Go to "Site administration / Plugins / Enrolments / Manage enrol plugins" and enable "Course meta link"
      3. Click on the "Course meta link"'s "Settings link.
      4. Set the following settings:
        Setting Value
        Roles that are not synchronised (enrol_meta | nosyncroleids) Manager, Course creator, Teacher, Non-editing teacher
        Synchronise all enrolled users (enrol_meta | syncall) No
        External unenrol action (enrol_meta | unenrolaction) Unenrol user from course
        Sort course list (enrol_meta | coursesort) Sort order
      5. Save the changes.
      6. Create a course C1.
      7. Enrol some students and teachers.
      8. Create another course C2.
      9. Go to C2's "Enrolment methods" page. (Course administration / Users / Enrolment methods)
      10. Under "Add method", select "Course meta link".
      11. On the "Course meta link" page, under "Link course", select C1.
      12. Click "Add method"
      13. Back on the "Enrolment methods" page, disable the "Course meta link (C1)" enrolment method.
      14. Navigate to "Site administration / Reports / Logs"
      15. Open a command line terminal and go to your moodle root directory.
      16. Enter the following command:

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

      17. Back on the "Logs" page, select logs for "C2" and select logs from the "CLI" and click "Get these logs".
      18. Check the results.
        • Confirm that there are no logs about users unenrolled from C2.
      19. Bonus: Hack enrol/meta/version.php and change the value of "$plugin->cron" to 60.
      20. Repeat steps 16-18 every minute for at least 3 times and confirm that there are no CLI logs about users being unenrolled from C2 after each scheduled task execution.
      Show
      Login as an admin Go to " Site administration / Plugins / Enrolments / Manage enrol plugins " and enable " Course meta link " Click on the " Course meta link "'s " Settings link. Set the following settings: Setting Value Roles that are not synchronised (enrol_meta | nosyncroleids) Manager, Course creator, Teacher, Non-editing teacher Synchronise all enrolled users (enrol_meta | syncall) No External unenrol action (enrol_meta | unenrolaction) Unenrol user from course Sort course list (enrol_meta | coursesort) Sort order Save the changes. Create a course C1. Enrol some students and teachers. Create another course C2. Go to C2's " Enrolment methods " page. (Course administration / Users / Enrolment methods) Under " Add method ", select " Course meta link ". On the " Course meta link " page, under " Link course ", select C1. Click " Add method " Back on the " Enrolment methods " page, disable the " Course meta link (C1) " enrolment method. Navigate to " Site administration / Reports / Logs " Open a command line terminal and go to your moodle root directory. Enter the following command: php admin/tool/task/cli/schedule_task.php --execute=\\core\\task\\legacy_plugin_cron_task Back on the " Logs " page, select logs for "C2" and select logs from the "CLI" and click " Get these logs ". Check the results. Confirm that there are no logs about users unenrolled from C2. Bonus: Hack enrol/meta/version.php and change the value of " $plugin->cron " to 60. Repeat steps 16-18 every minute for at least 3 times and confirm that there are no CLI logs about users being unenrolled from C2 after each scheduled task execution.
    • Affected Branches:
      MOODLE_27_STABLE, MOODLE_29_STABLE, MOODLE_31_STABLE
    • Fixed Branches:
      MOODLE_31_STABLE
    • Pull Master Branch:
      MDL-52186-master

      Description

      I've just finally understood a problem we have since more than one year, when using Moodle 2.7, and still present on Moodle 2.9.3 (and certainly 3.0, not tested).

      If you have meta-course enrolments defined in a course, but greyed (suspended/disabled), then it generates LOTS and LOTS of enrolments and unenrolments, regularly, all days (at all cron?).

      In my case i had a course with more than 1 500 000 lines of enrolments, and the same lines of unenrolments. And the same with "new" (from Moodle 2.7) logging and legacy logging.
      So, to speak simply : 7 000 000 lines of logs for nothing, due to a bug.
      And just for one course ; i had nearly 20 with this problem.

      The direct consequence (other than charging the server and taking lots of disk space) is that it breaks backups, and also course reports

      I suspect something is badly designed, always doing and undoing the same things

      If it can help, i've made a discussion (in French, but) with lots of understandable queries and datas :
      https://moodle.org/mod/forum/discuss.php?d=321252#p1293693 (for the start of the concerned messages)

      If you want to test it, just :

      1. use a platform with cron working
      2. activate both legacy and normal logs
      3. create a course A, with (lots of) users
      4. create a course B, and define a meta-link enrolment, disabled, pointing on course A
      5. after some time, look at the logs tables for course B

      With time, and cron executions, you'll see lots of things in :

      • mdl_logstore_standard_log concerning eventname = '\\core\\event
        user_enrolment_created' or eventname = '\\core\\event
        user_enrolment_deleted'
      • mdl_log concerning action='enrol' or action='unenrol'

      Séverin

        Attachments

          Activity

            People

            Assignee:
            jpataleta Jun Pataleta
            Reporter:
            fox Séverin Terrier
            Peer reviewer:
            Jun Pataleta
            Integrator:
            David Monllaó
            Tester:
            Mark Nelson
            Participants:
            Component watchers:
            Amaia Anabitarte, Carlos Escobedo, Ferran Recio, Sara Arjona (@sarjona), Víctor Déniz Falcón, Andrew Nicols, Jun Pataleta, Michael Hawkins, Shamim Rezaie, Simey Lameze
            Votes:
            1 Vote for this issue
            Watchers:
            7 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved:
              Fix Release Date:
              9/Jan/17