Repository navigation
proctored tests with multiple attempts per version may be inaccessible to students #3239
Description
This issue arises when a proctored_test assignment type allows multiple submissions per version. For example, a quiz that is a proctored_test and allows one version with two submissions. A student who only submits the quiz once (e.g., because they got all problems correct on the first attempt, or ran out of time and never submitted the quiz the second time) are then unable to view their work later because the test is still a proctored_test that requires proctor authorization to enter. I think this is because the conditional in the GatewayQuiz module that relaxes the assignment type from proctored_test to just test is triggered on the last submit of the test (I wonder who could have coded that logic into the module?).
If I'm correct, a possible solution is for the GatewayQuiz module to check the time limit for a proctored_test when a student goes to enter the test, and, if the test can no longer be submitted, reset the assignment type to allow access.
Activity
drgrice1 commentedon Oct 15, 2026
This can be fixed, but any fix could cause another issue. The fix would change the assignment type from
proctored_gatewaytogatewaywhen a student attempts to access the test again once the time (plus grade period) has expired. But since there are attempts remaining on that version, if the instructor were to extend the time by changing the close date for the test version, the student could then change answers in the test and grade the test again without proctor authorization to improve their score. One possible fix for that would be to change theattempts_per_versionfor the version to the number of submissions of the test at that point, but that could be confusing to the instructor if the instructor looks closely at the student's version and sees that student has less graded attempts per version allowed than other students. One thing that can make this even more confusing is that when viewing a test version for a student in the set details page, it is still shown as a "Proctored Test" (the global set setting is used for this, or perhaps it is taken from the student's template set which is also proctored -- I didn't check the code carefully) even though the version technically no longer is.How do you think that case should be handled?
Alex-Jordan commentedon Oct 15, 2026
I don't use proctored tests much, so I don't have skin in this game. But would it make sense to change the whole premise where
proctored_testis changed totest? Just leave it asproctored_test. And use some logic to bypass the proctor check even though it is still aproctored_test?drgrice1 commentedon Oct 15, 2026
Perhaps, but that would be a much bigger rewrite, and take considerably more effort.
somiaj commentedon Oct 15, 2026
I was going to mention something similar, the current approach of changing a completed proctored_test to a normal test to allow students to have access leads to a bunch of issues mentioned here.
What if instead of doing that, we update the proctor authentication module to give access to a test version based on if it is complete, has at least one submit and is past the due (or answer date) and then let the rest of the gateway module determine if problems can be seen, and if answers/solutions can be seen based on the other test settings?
I don't know how much of a rewrite it would be to just add some conditions to the proctor authentication module to move forward under reasonable conditions when accessing an existing test version.
drgrice1 commentedon Oct 15, 2026
It is definitely more than just a condition check in the proctor module. Most likely that approach would require a rather hefty revamp of the
GatewayQuizmodule.drgrice1 commentedon Oct 15, 2026
I implemented the "no type change" approach. It was not so much of a code rework as I thought. However, there are some efficiency issues with doing that. That is no small "condition" check really.
dlglin commentedon Oct 15, 2026
This is probably beyond the scope of this, but would it make sense to get rid of "proctored test" as a separate set type, and just make the proctoring options be settings of the regular test module?
somiaj commentedon Oct 15, 2026
@dlglin I was working with a branch that did that, and brought it up in a meeting. Basically it would be a lot of work and might not be worth of all the code changes needed. This would also require adding/updating other database fields to add an "No password" option on top of the "start only" and "both start and grade" options. The set type is basically working as the option on if a password is needed or not, so the update would mostly provide a visual change.
My alternative was making it so JavaScript will now show/hide the password field as you switch between proctored and non proctored tests. This way a page reload isn't needed if you want to switch to/from a proctored test to add/remove the password requirement.
dlglin commentedon Oct 15, 2026
At some point we need to move away from each setting for a set having its own DB field to just having a single field that contains all of the setting. That would greatly simplify making these sorts of changes.
Determine when a proctored test version is complete instead of changi…
Determine when a proctored test version is complete instead of changi…
Determine when a proctored test version is complete instead of changi…
Determine when a proctored test version is complete instead of changi…