Temporary override when student incorrectly loses registration access

[bmcutler]

What problem are you trying to solve with Submitty Approximately once per term we have corrupted datafeed. Students are incorrectly omitted from the course enrollment, and an automated script removes the student from the course. The student loses Submitty access and cannot obtain files, access the discussion forum, upload homework. Students send email, and must wait for the instructor or sysadmin to manually add them back into the course -- but precious time is lost.

Describe the way you'd like to solve this problem

Proposal:

• If a student has accessed a course recently but they are currently in the NULL registration section of an active course, they can temporarily re-add themselves to the course.

• "recently accessed" = has database access information within the last 24 hours (or maybe 48 or 72 hours?)

• database access information = most recent date in all the categories on the "Student Activity Dashboard"

• Their list of Submitty courses on the main "My Courses" Submitty page lists those courses as "Recently Dropped".

• If they click on that course (or otherwise directly access a course URL), instead of getting this message:

  

  They will instead get a message that says something like "You were recently removed from this course. If you believe this is an error, click here to re-add yourself to this course. An email will be automatically sent to both your instructor(s) and the system administrators so they are alerted about this potential error."

• These instructor & system administrator emails will be sent through the normal Submitty email system. I the student was indeed correctly removed from the course, then the instructor & system administrator can resolve the situation to permanently remove access if needed.

• If the daily registration scripts incorrectly remove the same students repeatedly, the student can keep re-enrolling themselves (and these emails will be repeatedly sent) until the situation is appropriately resolved.

• When we re-add a student to the course, we will need to know what that students "last valid registration section" was. We should add an additional column to the database and fill it in appropriately. Maybe this can just be stored in the course database? (I don't think it's necessary to store it in the master database and clutter up the trigger function.)

• If this last value registration section data is not available, we should still allow the student to be re-added, just put them in the first registration section. The email to the instructor and sysadmin should include the information about which section the student has been re-enrolled to (in case this is incorrect and the student needs to be moved).

Tagging @williamjallen @cjreed121 @NiaHeermance @pbailie for discussion.

Also linking this to the feature request for "self-registration" courses #3950

[bmcutler]

We should probably also consider adding a column with data on "date first added to course", and maybe also "date last removed from course". Also, at the very start of term maybe a student hasn't access a course at all, so maybe it can be "accessed course in last 24 hours or it's within the first 2 weeks of the start date of the term". We do store the start date of the term in the master database.

[NiaHeermance]

If an instructor later permanently removes a student from the course, how do we enforce the "permanence" if students can readd themselves? Maybe by using the "date last removed from course" column idea? So the message that allows students to readd themselves would only appear if the student was not removed from the course by the professor manually.

[bmcutler]

We could use the "Manual edit" status to disallow a student re-adding themselves.

Currently, we only use manual edit to prevent the automatic script from dropping a student (students marked manual are ignored / not edited by the automatic script). Students in the NULL section who are marked "manual" should not be given the option to self-re-enroll, even if they have recent access timestamp.

[NiaHeermance]

That makes sense. I think this is a great feature idea that would stop a lot of the headaches we talked about at RCOS today. 72 hours sounds better to me imo as it's possible a student might not check Submitty from, say, Friday night through Sunday morning if they're taking a break from their CS coursework.

[NiaHeermance]

We should probably also consider adding a column with data on "date first added to course", and maybe also "date last removed from course". Also, at the very start of term maybe a student hasn't access a course at all, so maybe it can be "accessed course in last 24 hours or it's within the first 2 weeks of the start date of the term". We do store the start date of the term in the master database.

For the "within the first 2 weeks of the start date of the term" condition to display the option, the student would have been added to the course in the first place, of course? We wouldn't want students to just be able to add themselves to any courses in the first 2 weeks of the term, ha ha.

[bmcutler]

Yes, I was think "currently in the null section AND (its the first 2 weeks of term OR student has accessed course recently)"

The "self registration" feature request (issue #3950 ) is for certain courses that do want to allow anyone with university access to be able to take (not required to be in the NULL section). E.g., the "crash course in C++" should be available to anyone who might take Data Structures in a future term. We could make other optional bonus courses for other courses or non-course related things.

[NiaHeermance]

Do we have any columns in the database that are the last time a student accessed a course? Or is that a column I should add to the database?

[bmcutler]

Look at how we determine the last access information on the "Student Activity panel" it shouldn't be necessary to add a column, but I suppose because the information is only stored in the course databases (not the main Submitty database) loading the "my course" page could be a performance concern...

[NiaHeermance]

Oh I'll look at that. Thanks so much!

[NiaHeermance]

When students are readded, they'll just be readded to section 1. Is that okay, or do you think we should store the last section a student was in so that is the section the student is readded to?

[bmcutler]

If we have the information, we should restore them to the last valid registration section. Being in the proper section is important for lab checkpoint grading.

Also, to add to the above, in addition to "last valid registration section" we should also have "last valid rotating section".

I realize this is a big issue, so tackling this in multiple PRs, and holding the implementation of these "last valid"s for a later PR is likely a good plan.

[NiaHeermance]

Rotating sections are just used for homework and test grading, right?

Okay! I think I'll readd to section 1 for now and a future PR will change it to the last valid section. I think we would need to add another database column so we remember what the last valid registration section was.