You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Suppose a student user in the LMS had email [email protected] and email prefix is being used for WeBWorK user IDs via LTI. It's halfway through the term and the student has completed some work in WeBWorK. User foo has lms_source_did set to whatever the LMS's ID is for that user.
Then the student has a name change or something that leads to their email now being [email protected]. Now the WW course has two users, foo and bar, each with the same lms_source_did. The student enters WW as bar now and cannot see their progress from when they were foo. In the past we've discussed merging two users but it's hard to work out how some of the details would be handled, and I am not asking about merging two users for now.
Instead, the immediate issue is that foo and bar have the same lms_source_did. So when grade passback happens at the mass update, maybe bar's scores are sent to the LMS, but then foo's scores are also sent and they overwrite whatever recent scores bar has earned. Or it could be the other way around. To the student in the LMS, they end up seeing either scores from foo or from bar, and zeros (or non-initialized scores) for half the assignments.
Manually, I think what I need to do (since this is happening with a student right now) is to copy foo's scores over to bar within WeBWorK. Then remove foo's lms_source_did directly using sql. And if the student has some reason they should access user foo to see their old work, give them password access. Is there a better solution to this?
The text was updated successfully, but these errors were encountered:
I think that is the best way at this point. It will take a bit of effort, but I am sure you can handle it.
Perhaps we need another database column that saves user's lms_source_id. Then LTI authentication should be reworked to use that to associate the user from the LMS with the webwork user. The lms_source_id would be saved on initial sign on when the user is created. A fallback would need to be used for instructors and such above the course creation cutoff. This would mean that if the user's email address changes, then the association would still succeed, and no new user would be created.
I realized my previous comment here was silly. We don't need another database column to save the user's LMS id. We already have one, and it is in fact already saving the LMS id (just only in the case that grade pass back is enabled).
Suppose a student user in the LMS had email
[email protected]
and email prefix is being used for WeBWorK user IDs via LTI. It's halfway through the term and the student has completed some work in WeBWorK. Userfoo
haslms_source_did
set to whatever the LMS's ID is for that user.Then the student has a name change or something that leads to their email now being
[email protected]
. Now the WW course has two users,foo
andbar
, each with the samelms_source_did
. The student enters WW asbar
now and cannot see their progress from when they werefoo
. In the past we've discussed merging two users but it's hard to work out how some of the details would be handled, and I am not asking about merging two users for now.Instead, the immediate issue is that
foo
andbar
have the samelms_source_did
. So when grade passback happens at the mass update, maybebar
's scores are sent to the LMS, but thenfoo
's scores are also sent and they overwrite whatever recent scoresbar
has earned. Or it could be the other way around. To the student in the LMS, they end up seeing either scores fromfoo
or frombar
, and zeros (or non-initialized scores) for half the assignments.Manually, I think what I need to do (since this is happening with a student right now) is to copy
foo
's scores over tobar
within WeBWorK. Then removefoo
'slms_source_did
directly using sql. And if the student has some reason they should access userfoo
to see their old work, give them password access. Is there a better solution to this?The text was updated successfully, but these errors were encountered: