Configuration changes in rating and matchmaking implementations is not persisted if changed in class

[skrede]

Let's say the class in capquiz/classes/matchmaking/n-closest/n_closest_selector.php modifies its configuration. Consider the field '$prevent_same_question_for_turns' which it will decrement while no new questions are selected. The changes done after decrementing is not stored for the next attempt, and it will decrement again.

In practice, if the number specified is too big (in this case it is set longer than the list of questions, for testing purposes), after the student has answered all questions, the student will eventually answer all questions in the same order.

As of now, the class will decrement N itself until a question is finally matched. See issue #57

Solving this issue will not really solve issue #57, as it will always draw one question in a deterministic order. I think it is best to trust the instructor.

[hgeorgsch]

I agree that it is best to trust the instructor when it comes to the blacklist length versus question list length.
Do I understand it correctly that if #57 is resolved, this issue ceases to be a problem?
If that's correct, we should definitely drop all ad hoc solutions and let students run out of question. Then both issues can be closed.

[hgeorgsch]

As discussed in meeting 22 August, this issue does not affect the user at all. It is a limitation in the API which may or may not turn into a bug when/if the developer tries to use the API in a new but intuitive way.