WeBWorK Main Forum

LTI auto-enrollment and visible assignments

LTI auto-enrollment and visible assignments

by D. Brian Walton -
Number of replies: 2
As we prepare to switch to using LTI-authentication and auto-enrollment in WeBWorK, I have some questions about how problem sets are assigned. From the documentation, it appears that when students log into WeBWorK via LTI for the first time, the user record is created and that student is assigned to every visible problem set.

1) "Visible" now means something different as it is being used to mean "Assigned". Has this created problems for anyone? I know that I often have been burned by forgetting to make an assignment visible when I create it. It is now part of my practice to set "Visible" at the same time I first edit the available/due/answer dates just so that I don't forget.

Apparently that will need to change because students might potentially login for the first time and have access to a problem set that I'm not ready to release but have marked visible. Is this a correct understanding of the situation?

2) What have you done about students enrolling late? Suppose I have assigned some early assignments that are due during that first week and that I have marked that the answers are available immediately when the set closes.

In the past, when a new student enrolls, they are not automatically assigned the problem set so as an instructor I can add them to the assignment and concurrently shift the assignment dates to account for their special circumstances. But with the LTI auto-enrollment, as an instructor I will not see any notifications. They will be able to access a closed problem set and see solutions before asking for help to open the problem set with customized dates.

Has anyone worked through a solution to this challenge?

3) Are there other surprises that you've encountered?


Brian Walton
James Madison University
In reply to D. Brian Walton

Re: LTI auto-enrollment and visible assignments

by Danny Glin -
1) "Visible" and "Assigned" are two different, orthogonal conditions for an assignment. "Visible" applies to an assignment for the whole class, whereas "Assigned" applies to an assignment for each student. In order for a student to be able to access an assignment, it has to be visible to the class, and assigned to that student.

Your understanding appears to be correct. There are a couple of things that may help:
If you are worried about forgetting to make an assignment visible, you can set the open date for assignments that are not ready to release to be in the future. This way it will be auto-assigned to new enrolees, but they won't be able to access it yet.

Alternatively you can change the assignment to hidden while you work on it. When it is ready, you will need to do two things: make it visible and assign it to all users. Note that "Assign to all users" does not affect users to whom it is already assigned, so this should be safe to do even if it was already assigned to some users.

2) We have had this issue for years, as we set up our own batch-enrol process that happens nightly. The way I've handled this is to unassign and reassign the assignment to the latecomer, and then change the dates. This way their problems get rerandomized, so although they have had access to the answers (and possibly solutions) of a previous version, they now have different numbers to work with. Be careful when unassigning, as it deletes all student progress for the assignment, which is not an issue if the student only came in after the due date.

Beyond these I haven't had any complaints about the LTI auto-enrolment. We are not using the grade passback at this time, though it's something I'd like to explore in the future.
In reply to D. Brian Walton

Re: LTI auto-enrollment and visible assignments

by Andras Balogh -
Regarding your question #2:
I am only testing LTI myself, but I see in authen_LTI.conf that there are settings to automatically "extend due dates based off the number of problems students have to do":

#$LTI_modify_user_set = sub {
# # The self object from LTIAdvanced.pm
# my $self = shift;
# my $globalSet = shift;
# # The userSet object to be modified
# my $userSet = shift;

# my $numberOfSetsAssigned = $self->{numberOfSetsAssigned};
# my $daysPerSetMakeup = 2;
# my $reasonableNumberOfDays = $numberOfSetsAssigned*$daysPerSetMakeup +1;
# if ($reasonableNumberOfDays < 2) {$reasonableNumberOfDays = 2;}
# my $niceDueTime = $globalSet->due_date + $reasonableNumberOfDays*86400;
# my $niceAnswerTime = $niceDueTime + 600;
# $userSet->due_date($niceDueTime);
# $userSet->answer_date($niceAnswerTime);

Maybe one can write a subroutine to extend the due date based on when the student account is created.