courses: do something sensible when a student deletes their account

[williamstein]

Deleting an account is not something a student could accidentally do - there's a huge warning, etc. However, students sometimes do it in a panic. In fact, in just one single recent class 17 students deleted their accounts and over 60 accounts were deleted in the last week. So it happens.

In our course code, I think we assumed that people don't delete their accounts on whim; in fact, much of the course code was written before there was account deletion functionality. If they do delete their account, it's going to take some manual work to fix things. Once they make their first account, that is the one associated to the course. If they then delete their account and make a new one with the same email address, they are going to be in big trouble and probably the only possible fix right now is for them to get added as a new student with a different email address.

Honestly, I'm not even sure what the semantics for this should be.

[mforbes]

I ran into this warning today when I tried to delete a test account I made for myself to see what students see. As far as semantics go, my expectation would be that if a student deletes their account, then they would be "de-registered" from the course, removed from the shared project, and have their student project deleted so that everything is returned to the prior state.

Probably not the best sementics though for students who accidentally delete their account and don't want all their work lost etc. though.

[novoselt]

It does not seem that we have to deal with 60 accidentally deleted projects per week anymore, so the current behaviour is reasonably sensible.

[williamstein]

We also have a big message right in the delete box about this which points to this issue:

Evidently, people do read it.

[williamstein]

Crazy -- just a few minutes after I posted my comment a student opened a support request in which they deleted their account to "To try to fix it", and now they are locked out from their course, etc. We haven't had this happen in months (or years), and it happens moments after discussing it.

[williamstein]

The feedback from the student was basically: "I saw and read the above message, but the TA told me to delete my account anyways."

Obviously this issue needs to stay open.

[williamstein]

How to fix this:

• figure out the new account_id of the student
• close the .course file in cocalc
• edit the .course file (e.g., using vim) and replace the old account_id with the new one
• open the .course file

This fixes the problem.

A user can basically change their account_id at any time as follows:

• delete their account thus freeing up their email address
• create a new account with the old email address

The "Reconfigure all students" button (i.e., action) should also have a step where it queries an api endpoint with a list of all known email addresses of students for the corresponding account_id's. If any change, then it changes them in the .course data. Anyway, I think that's the best we can do for a longterm fix for this problem.

[novoselt]

Will it affect students who change their emails associated to the account after being enrolled in a course?

[williamstein]

Will it affect students who change their emails associated to the account after being enrolled in a course?

If they change their email address, then make another new account with the old email address, it would impact them. I mean, what should happen in that scenario?

An alternative would be to add a new api call which allows the frontend to ask: "which of the following account_id's do not currently exist (presumably due to being deleted)?" For each such address it would just do the standard thing to add the user with the corresponding email to the course. A problem with that strategy though is that students can be added to a course by name without knowing their email address ever (or maybe they don't even have one), so there is no way to add them at this point.

Also, one I'm proposing here to solve this problem only works if the student got added to the course by email address so maybe this whole solution is wrong. Another approach would be the following:

• assume a student gets added to the course in any way, and their account exists, so we know the account_id.
• the student then deletes their account.
• we could just completely delete the student from the course and purge them entirely from the course file (so they can't even be undeleted, etc.)
• then the instructor can easily add the actual student again, since the old record isn't there.

This seems pretty horrible though. E.g., imagine this happens halfway through the course -- suddenly you don't have the ability to view the students homework and other records, which is ridiculous. So this is not a solution at all.

Here's another idea:

• the student is added to the course somehow
• the student deletes their account
• the .course detects this via an api that, given an account_id, tells whether or not that account still exists
• it then explicitly removes the account_id from the student's record in the .course file. Hopefully the old student name is still in there so there is some way to identify the student.
• the UI then shows what we know about the student and has an alert that says "this student deleted their account; would you like to add them again?"
• the instructor can then manually add the student again via an entirely new UI element, and this could involve adding the student by searching for them via name or email. If an account exists they get added. If there's no account, an email invite gets sent out, the student makes an account and eventually the .course notices and sets the account_id with this new account.

I think the above would at least work in general. but it's quite a lot of work to implement, and unlike all the other ideas, it involves explicit action by the instructor.