Moodle

Unenroled User still limits the choices of a course

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Duplicate
  • Affects Version/s: 1.8.2
  • Fix Version/s: None
  • Component/s: Choice
  • Labels:
    None
  • Database:
    MySQL
  • Affected Branches:
    MOODLE_18_STABLE

Description

If a choice has the settings that the responses are limited and that a user can update the choice, there ist the following error: The user chooses an option. After that this user unenroles himself out of the course. In the choice is the taken option of this user not visible any more. The text under the taken option displays also "Taken:0". But the possible choices of this option are still limited as if the taken option of this user would still count. A look in the database shows that the taken option of this user is still availible in the table "choice_answers".

If a user unenroles from a course, then should his taken options in answers of this course be deleted.

Issue Links

Activity

Hide
Dan Marsden added a comment -

Thanks Robert - I haven't seen this particular issue before! - I'll have a look at it first thing tomorrow morning.

Dan

Show
Dan Marsden added a comment - Thanks Robert - I haven't seen this particular issue before! - I'll have a look at it first thing tomorrow morning. Dan
Hide
Steve Bond added a comment - - edited

I've just come across this same problem in 1.8.3.

My first thought was to go to course/unenrol.php and make that remove the user's selection from mdl_choice_answers. But the comments at the top of unenrol.php say:

// This will not delete any of their data from the course,
// but will remove them from the participant list and prevent
// any course email being sent to them.

I guess it makes sense to keep it that way, and it makes sense to preserve the choices of users who are unenrolled, so they are still there if and when they decide to re-enrol.

On the other hand, if we were to modify the function choice_show_form() in choice/lib.php, so that it doesn't count unenrolled users when determining whether a particular option is full, then what happens in this scenario?:

User A chooses option 1 when it is not full
User A unenrols
Other users choose option 1 and it becomes full
User A re-enrols

Now (I think) we end up with more than the maximum # of users in option 1.

I'm not really sure of the best way to get around this. Maybe a simpler solution is to keep the status quo, but display unenrolled user choices as "Unenrolled user", or "Username (unenrolled)". Then it is up to the teacher whether they decide to remove those choices.

Steve

Show
Steve Bond added a comment - - edited I've just come across this same problem in 1.8.3. My first thought was to go to course/unenrol.php and make that remove the user's selection from mdl_choice_answers. But the comments at the top of unenrol.php say: // This will not delete any of their data from the course, // but will remove them from the participant list and prevent // any course email being sent to them. I guess it makes sense to keep it that way, and it makes sense to preserve the choices of users who are unenrolled, so they are still there if and when they decide to re-enrol. On the other hand, if we were to modify the function choice_show_form() in choice/lib.php, so that it doesn't count unenrolled users when determining whether a particular option is full, then what happens in this scenario?: User A chooses option 1 when it is not full User A unenrols Other users choose option 1 and it becomes full User A re-enrols Now (I think) we end up with more than the maximum # of users in option 1. I'm not really sure of the best way to get around this. Maybe a simpler solution is to keep the status quo, but display unenrolled user choices as "Unenrolled user", or "Username (unenrolled)". Then it is up to the teacher whether they decide to remove those choices. Steve
Hide
Dan Marsden added a comment -

closing this as a duplicate of MDL-12083

I think the best way to approach it would be manage it via cron as mentioned in MDL-12083

Dan

Show
Dan Marsden added a comment - closing this as a duplicate of MDL-12083 I think the best way to approach it would be manage it via cron as mentioned in MDL-12083 Dan

People

Vote (1)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: