student viewing results: the spinner keeps going until the user clicks on the page

[damithc]

v8.23, production
Reported by a user, reproducible

When the student is viewing results using a link, the spinner for questions keep going indefinitely, until the user clicks on the page. After that, the questions show up.

Doesn't seem to affect everyone but students in this particular course is affected, so perhaps it depends on the question configuration. The first and second questions are weighted rubric question.

The rest are essay questions:

Let me know if you need more info.

[samuelfangjw]

Possibly related to #12068

[damithc]

Possibly related to #12068

@samuelfangjw Yup, most likely. It seems to affect other type of questions in the page as well. Can we get someone to fix it soon?

[zhaojj2209]

After much investigation, I think I have a general idea of what is happening:

When a student views the results of a feedback session, the frontend initially calls GetFeedbackQuestionsAction (/webapi/questions) to retrieve the list of questions for this feedback session, then loads the results lazily by calling GetSessionResultsAction (/webapi/result) for each question depending on whether the response panel is in the viewport.

However, GetFeedbackQuestionsAction hides the rubric weights for students viewing feedback results (intent=STUDENT_RESULT). This causes the weights to be an empty array even though hasWeights is set to true, therefore an array access error is thrown in the console when calculating the statistics (as it accesses the weights array if hasWeights is true), causing the frontend to "halt" and the spinner to load infinitely.

Clicking causes activity to resume, and after GetSessionResultsAction is called, no error is encountered when calculating rubric statistics because GetSessionResultsAction does not hide the rubric weights when intent=STUDENT_RESULT.

The fix here would therefore be to add an extra check and calculate statistics only if the weights array is not empty. This would allow the frontend to load the responses without any errors.

However, I believe there is a much, much more serious issue here: the weights are not being hidden from the students in GetSessionResultsAction. This means that students would be able to view weights related statistics (e.g. per recipient stats) even though they are not supposed to (see below screenshot of student view responses page).

@damithc Can I confirm if students should not have any knowledge on whether the rubric question is weighted (so the statistics they view for weighted rubric questions should be the same as if the question was not weighted)? I will be adding the extra fix to hide rubric weights in GetSessionResultsAction as well.

[damithc]

@damithc Can I confirm if students should not have any knowledge on whether the rubric question is weighted (so the statistics they view for weighted rubric questions should be the same as if the question was not weighted)? I will be adding the extra fix to hide rubric weights in GetSessionResultsAction as well.

@zhaojj2209 thanks for investigating this. I feel students should know that the rubric is weighted and also know the weights, when they are submitting responses as well as when they are viewing results. In fact knowing the weights can help them make more informed decisions when evaluating. So, there is no need to hide the weights. What do you guys think? Or did I misunderstand the question?

[zhaojj2209]

@damithc As shown in the above screenshot, the students are able to view the per recipient statistics of other students as well, which I believe is not intended as these statistics are meant for instructors. This is because the rubric stats table component is shared between the instructor view results and student view results pages, but it does not differentiate between student and instructor; whether or not the per recipient statistics are shown is solely dependent on whether the question has weights.

The faster fix right now would be to hide weights from the students so that the per recipient statistics will also be hidden from the students. Given that rubric weights are deliberately hidden from students in GetFeedbackQuestionsAction, I think the current intended behaviour should be to hide weights from students altogether, so this fix would also be in line with the current intended behaviour.

We can leave the showing of weights to students as a separate issue, as that will require more changes (specifically, unhiding the weights from students on the backend side, and refactoring the frontend rubric stats table to differentiate between student and instructor).

[damithc]

@damithc As shown in the above screenshot, the students are able to view the per recipient statistics of other students as well, which I believe is not intended as these statistics are meant for instructors.

Yes, that should not be shown to students. This is a serious data leak. Must be fixed ASAP.

e can leave the showing of weights to students as a separate issue, as that will require more changes (specifically, unhiding the weights from students on the backend side, and refactoring the frontend rubric stats table to differentiate between student and instructor).

Agreed.

[samuelfangjw]

@damithc As shown in the above screenshot, the students are able to view the per recipient statistics of other students as well, which I believe is not intended as these statistics are meant for instructors.

Yes, that should not be shown to students. This is a serious data leak. Must be fixed ASAP.

This is not a data leak. Students cannot see results of other students. The results table is constructed from the results given and received by the student.

[samuelfangjw]

This should still be removed though, doesn't really make sense to have per recipient stats in the context of student responses.

[zhaojj2209]

This is not a data leak. Students cannot see results of other students. The results table is constructed from the results given and received by the student.

My bad for the misconception! So the per recipient stats tables would only be showing the responses that the user gave to other students.

Nevertheless, I agree that it doesn't make sense for the per recipient tables to be there.

[damithc]

Agreed, not really a data leak, but best to be removed from view.