after copying a course, error messages from trying to copy a proctored test

[Alex-Jordan]

There was a course with a proctored test named Final_Exam_F24 that used Proctor Authorization Type "Only Start". I'm not familiar with how this works, but the course has a user in the database with ID set_id:Final_Exam_F24 that I guess has something to do with proctor authentication.

The course was copied, including copying assignments and non-student users. So the new course has Final_Exam_F24. I'm not sure if user set_id:Final_Exam_F24 should be copied into the new course, but they were not. Maybe these special users are excluded from the tool that generates the list of non-student users to copy.

The instructor was in the new course, in the Sets Manager, and used the Create tab to make a new set named Final_Exam_SP25 that would be a copy of Final_Exam_F24. And this caused an error message:

 Can't call method "user_id" on an undefined value at /opt/webwork/webwork2/lib/WeBWorK/ContentGenerator/Instructor/ProblemSetList.pm line 506.

Looking at that line, there seems to be an expectation that user set_id:Final_Exam_F24 should exist. And it would be copied to a new user set_id:Final_Exam_SP25.

Since I am not familiar with the purpose of these users, I am not sure how to fix this. Perhaps it should only try to create the new user if the old one exists? Or perhaps the set_id:... users from the old course should have been copied over?

[somiaj]

There is an option that allows you to give the proctored test a set password. If there is a set password, then a user is created to store that password which is used to start the test (this allows having just a single password to open the test, vs a user with proctor permission which requires both the username/password, useful if you want to share a password to control who starts the test).

Since these are 'fake' users, most database calls exclude them as they are really only needed to start the proctored test, so they were probably excluded due to that. I have a proctored test that I copied but haven't used this semester and I can confirm the issue when trying to copy the set. But looking closer I noticed that the original copy I'm able to modify it just fine and it loads just fine without a password, and it acts as if the password was not copied over, I just cannot create a copy of it.

I think we have various ways to fix this, the easiest might just be add a condition at line 506 in ProblmeSetList.pm that checks if the user exists, which would avoid the error. The side effect of just avoiding the error is the set password would not be copied to the new set, which would require the user to create a new set password.

Another option is when coping the sets to the new course, is to set the option restricted_login_proctor to No when copying the assignment over (this is the option that is set to state there is a set password). This will also disable the set password on the copied assignment, making it so the instructor will have to create a new password for the set, but things will function correctly when copying the assignment as the set will not think it has a set password that needs copied.

Outside of the instructor having to create a new set password, there shouldn't be any other issues with either of the above approaches I can think of. The test is still a proctored test, it just can no longer be started with a single password, and instead would require a user with proctor permissions to enter in their credentials to start the test.

Last, we could just copy over all the set_id: users and their passwords, this would then copy the set password to the new course.

I'm unsure which would be best, but for my use case, I probably won't recall what the set password is anyways and I am always going to create a new one, so for me there is no reason to copy that user over and make the instructor have to set a new set password.

[drgrice1]

I think the best solution would be to copy set level proctor users when copying the course in the case that assignments are copied. Whether this is done or not should have nothing to do with if users are copied. Of course this may be the most difficult approach to implement.