after copying a course, error messages from trying to copy a proctored test #2652
Comments
|
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 Another option is when coping the sets to the new course, is to set the option 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. |
|
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. |
If sets are copied then everything for that set should be copied. These set level proctor users belong to the set. This fixes issue openwebwork#2652. Also add a missing `maketext` call in the related template. Also fix some database list/get usage that I missed when these copy options were implemented. Never list all database records if you are going to subsequently get all records anyway. Listing records is the equivalent of calling `SELECT id from table` and getting all records is the equivalent of calling `SELECT * from table`. Why would you inneficiently first list to get id's and then select everything separately? Note that you can get always get all records by using the webwork2 db `Where` methods with no where clause. Note that the copying of sets that is done here is still highly inneficient. The current approach gets all sets, and then loops through those sets, then gets the problems for that set and loops through those adding one at a time, then gets set locations and loops through adding one of those at a time, and now adds the set level proctor (of which there can be only one). Instead since all sets are being copyied all sets could be fetched and added at once, then all problems for all sets fetched and added at once, then all set level proctors for all sets fetched and added at once. However, adding all at once like that takes for effort because there aren't convenience database methods for doing that. This is now done when assigning sets to multiple users (I helped @taniwallach implement that) and the same could be done here. Note that for a course with a large number of sets and a lot of problems the current approach is quite slow.
If sets are copied then everything for that set should be copied. These set level proctor users belong to the set. This fixes issue openwebwork#2652. Also add a missing `maketext` call in the related template. Also fix some database list/get usage that I missed when these copy options were implemented. Never list all database records if you are going to subsequently get all records anyway. Listing records is the equivalent of calling `SELECT id from table` and getting all records is the equivalent of calling `SELECT * from table`. Why would you inneficiently first list to get id's and then select everything separately? Note that you can get always get all records by using the webwork2 db `Where` methods with no where clause. Note that the copying of sets that is done here is still highly inneficient. The current approach gets all sets, and then loops through those sets, then gets the problems for that set and loops through those adding one at a time, then gets set locations and loops through adding one of those at a time, and now adds the set level proctor (of which there can be only one). Instead since all sets are being copyied all sets could be fetched and added at once, then all problems for all sets fetched and added at once, then all set level proctors for all sets fetched and added at once. However, adding all at once like that takes for effort because there aren't convenience database methods for doing that. This is now done when assigning sets to multiple users (I helped @taniwallach implement that) and the same could be done here. Note that for a course with a large number of sets and a lot of problems the current approach is quite slow.
If sets are copied then everything for that set should be copied. These set level proctor users belong to the set. This fixes issue openwebwork#2652. Also add a missing `maketext` call in the related template. Also fix some database list/get usage that I missed when these copy options were implemented. Never list all database records if you are going to subsequently get all records anyway. Listing records is the equivalent of calling `SELECT id from table` and getting all records is the equivalent of calling `SELECT * from table`. Why would you inneficiently first list to get id's and then select everything separately? Note that you can get always get all records by using the webwork2 db `Where` methods with no where clause. Note that the copying of sets that is done here is still highly inneficient. The current approach gets all sets, and then loops through those sets, then gets the problems for that set and loops through those adding one at a time, then gets set locations and loops through adding one of those at a time, and now adds the set level proctor (of which there can be only one). Instead since all sets are being copyied all sets could be fetched and added at once, then all problems for all sets fetched and added at once, then all set level proctors for all sets fetched and added at once. However, adding all at once like that takes for effort because there aren't convenience database methods for doing that. This is now done when assigning sets to multiple users (I helped @taniwallach implement that) and the same could be done here. Note that for a course with a large number of sets and a lot of problems the current approach is quite slow.
If sets are copied then everything for that set should be copied. These set level proctor users belong to the set. This fixes issue openwebwork#2652. Also add a missing `maketext` call in the related template. Also fix some database list/get usage that I missed when these copy options were implemented. Never list all database records if you are going to subsequently get all records anyway. Listing records is the equivalent of calling `SELECT id from table` and getting all records is the equivalent of calling `SELECT * from table`. Why would you inneficiently first list to get id's and then select everything separately? Note that you can get always get all records by using the webwork2 db `Where` methods with no where clause. Note that the copying of sets that is done here is still highly inneficient. The current approach gets all sets, and then loops through those sets, then gets the problems for that set and loops through those adding one at a time, then gets set locations and loops through adding one of those at a time, and now adds the set level proctor (of which there can be only one). Instead since all sets are being copyied all sets could be fetched and added at once, then all problems for all sets fetched and added at once, then all set level proctors for all sets fetched and added at once. However, adding all at once like that takes for effort because there aren't convenience database methods for doing that. This is now done when assigning sets to multiple users (I helped @taniwallach implement that) and the same could be done here. Note that for a course with a large number of sets and a lot of problems the current approach is quite slow.
There was a course with a proctored test named
Final_Exam_F24that used Proctor Authorization Type "Only Start". I'm not familiar with how this works, but the course has a user in the database with IDset_id:Final_Exam_F24that 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 userset_id:Final_Exam_F24should 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_SP25that would be a copy ofFinal_Exam_F24. And this caused an error message:Looking at that line, there seems to be an expectation that user
set_id:Final_Exam_F24should exist. And it would be copied to a new userset_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?The text was updated successfully, but these errors were encountered: