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

Workshop: Remove groupmembersonly checks

XMLWordPrintable

    • Icon: Improvement Improvement
    • Resolution: Won't Fix
    • Icon: Minor Minor
    • 2.7
    • 2.7
    • Workshop
    • None
    • MOODLE_27_STABLE
    • MOODLE_27_STABLE
    • MDL-44683-master
    • Hide

      0. Enable groupmembersonly option at system level.
      1. Create a new course.
      2. Enrol 3 test users into the course (I'll call them 1, 2, and 3).
      3. Create a group. Add users 1 and 2 to this group. Do not add user 3 to a group.
      4. Create a Workshop with default settings, except turn on group members only.
      5. Change the workshop to submissions phase.
      (You may want to use a different browser for the next steps)
      6. Log in as user 1 to the workshop. Submit some text.
      7. Log in as user 2 and submit some text.
      (Back to the main browser)
      8. From the admin menu, choose 'Allocate submissions'.

      EXPECTED: The list shows users 1, 2, and 3. From the dropdowns, you could allocate the two assignments to either of the other users.

      9. Choose 'Random allocation' tab.
      10. Set number of reviews to 2 per submission.
      11. Tick 'Participants can assess without having submitted'
      12. Save changes.

      EXPECTED: Without complaining, the system allocates the assignments for review to both other users (including user 3).

      (end)

      NOTE: The behaviour in this part of the test case would be slightly undesirable in real life. It is expected that, if you want users to be randomly assigned only to users in groups, you should set the group mode for the activity. (Or you can use manual assignment.)

      Show
      0. Enable groupmembersonly option at system level. 1. Create a new course. 2. Enrol 3 test users into the course (I'll call them 1, 2, and 3). 3. Create a group. Add users 1 and 2 to this group. Do not add user 3 to a group. 4. Create a Workshop with default settings, except turn on group members only. 5. Change the workshop to submissions phase. (You may want to use a different browser for the next steps) 6. Log in as user 1 to the workshop. Submit some text. 7. Log in as user 2 and submit some text. (Back to the main browser) 8. From the admin menu, choose 'Allocate submissions'. EXPECTED: The list shows users 1, 2, and 3. From the dropdowns, you could allocate the two assignments to either of the other users. 9. Choose 'Random allocation' tab. 10. Set number of reviews to 2 per submission. 11. Tick 'Participants can assess without having submitted' 12. Save changes. EXPECTED: Without complaining, the system allocates the assignments for review to both other users (including user 3). (end) NOTE: The behaviour in this part of the test case would be slightly undesirable in real life. It is expected that, if you want users to be randomly assigned only to users in groups, you should set the group mode for the activity. (Or you can use manual assignment.)

      Logic relating to allocating users and showing lists of participants used to take the 'groupmembersonly' flag into account. In preparation for MDL-44070, I would like to remove the code that uses this flag.

      I have changed the code so that it behaves as if enablegroupmembersonly (which was always listed as an experimental feature) had been turned off.

      This will cause the following changes to behaviour:

      Manual assignment:

      • If groupmembersonly was enabled before, the list of potential users (under 'Manual allocation') would include only users who are in groups. Now it includes all enrolled users.

      Random assignment:

      • If groupmembersonly was enabled before, AND the assignment is set to 'no groups' mode, AND you choose the 'partipants can assess without having submitted anything' option, then the random allocation system would previously not allocate assignments for review to users who were not in a group. Now it will allocate to these users, even though (because of groupmembersonly) they cannot access the activity.

      Note: Both before and now, it is possible for random assignment to allocate assignment to users who cannot access the activity for other reasons e.g. if there is a user profile condition.

      I have discussed this with David Mudrák. Because it doesn't actually depend on any of MDL-44070, and because it includes a slight behaviour change, I decided it was best to submit this as a separate issue first.

            quen Sam Marshall
            quen Sam Marshall
            David Mudrák (@mudrd8mz) David Mudrák (@mudrd8mz)
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved:

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