EVAL is an educational platform for managing training exercises and exams, featuring specialized question types for software engineering education and training.
Create an evaluation and keep it in the draft phase.
Join the evaluation as a student using the link.
Restrict access to the evaluation (with students already in).
A student who has already joined tries to access it again.
Effects:
The student is not allowed to enter even if they had already joined the evaluation before the restriction was activated.
The professor's view presents conflicting information; the student appears both in the registered students list and in the denied students list.
The professor can use the "add to access list" button to allow the student to enter.
If the student was manually added to the access list before the evaluation was set to in-progress, they remain in the list of denied students while they still have access to the evaluation (as they are part of the access list - which is ok). In this case, the "add to access list" button does not remove the student from the denied list because they are already in the access list - which is not ok.
Fix:
DRAFT PHASE:
We must decide, or let the user decide, what to do with students who have already joined before the restriction was activated. The professor could choose to add them to the access list or to remove them from the evaluation (so they don’t appear in the registered students). This involves deleting all the pre-generated empty answers for the student. Alternatively, we could choose one of these actions by design. Adding them to the access list would be easier to implement and would make sense for most cases.
What do we do when the already registered student is being removed from the access list input field? In this case, it makes more sense to remove the student from the evaluation, or to prevent the removal of the registered student from the access list. A confirmation / alert dialog would be necessary. Note that if the student uses the link later (DRAFT or IN PROGRESS), they will end up in the denied student list and can be allowed to enter using "add to access list".
Another option: Make the restriction toggle button read-only if someone has already registered for the evaluation. Professors usually join their own evaluation in the draft phase. Implementing this could lead to issues and the necessity to recreate the evaluation if they wish to activate the restricted access later on.
Ovich
commented
4 months ago
Reproduction:
Effects:
Fix:
DRAFT PHASE:
We must decide, or let the user decide, what to do with students who have already joined before the restriction was activated. The professor could choose to add them to the access list or to remove them from the evaluation (so they don’t appear in the registered students). This involves deleting all the pre-generated empty answers for the student. Alternatively, we could choose one of these actions by design. Adding them to the access list would be easier to implement and would make sense for most cases.
What do we do when the already registered student is being removed from the access list input field? In this case, it makes more sense to remove the student from the evaluation, or to prevent the removal of the registered student from the access list. A confirmation / alert dialog would be necessary. Note that if the student uses the link later (DRAFT or IN PROGRESS), they will end up in the denied student list and can be allowed to enter using "add to access list".
Another option: Make the restriction toggle button read-only if someone has already registered for the evaluation. Professors usually join their own evaluation in the draft phase. Implementing this could lead to issues and the necessity to recreate the evaluation if they wish to activate the restricted access later on.