1/ type/match/tests/walkthrough_test.php - tests are failing randomly, looks like some weird randomisation is going on there - see TODOs
2/ type/multianswer/tests/upgradelibnewqe_test.php contains invalid expected value - see TODO
None of these problems affect the default roles. They only occur when
the permissions have been edited to allow restricted subsets of the
question capabilities.
In some cases, things that the restriced subset of capabilities should
have allowed were blocked by errors. In other cases, users were allowed
to do more than they should bave been due to failures to check the
right capabilities in the right places.
For full details, see the bug report.
Two of the bugs were previously reported separately as MDL-26395 and
MDL-27232.
Sadly, this involves a small API change, but I don't believe anyone was
using the argument I had to remove (because we were sometimes passing a
wrong value, and there is not way to compute the right value at that
point in the code.)
Also sadly, the code to compute the context we are importing into is now
rather spaghetti-like, but it works.
Also, some MySQL-only code had not been updated.
This problem only affected a small minority of question attempts, like
this:
1. Suppose you have a shortanswer question with correct answer 'Toad'
and some hints.
2. Suppose a student attempts this using the interactive behaviour and
on the first try responds 'Frog', and on the second try responds 'Toad'.
3. Then suppose the teacher edits the question to make 'Frog' correct.
4. Then, when the quiz is regraded, the question_attempt_step for the
second try will need to be deleted. That is where the buggy code was.
The files that belong to the question hints are neither moved when the
question is moved to another context, nor deleted when the question is
deleted.
Oops! How come no one noticed that until today.
The problem was mostly that, in the past, we did not worry if
question_attempt_step.id changed during regrade (because we deleted the
old step row and inserted a new one). However, now that steps can have
associated files, we can't be that slack, becuase the step id is used as
the file itemid.
So, now, we have to update the existing rows during a regrade. We do
this by having the question engine tell the question_engine_unit_of_work
that the step has first been deleted, and then added back. Then we make
the unit-of-work spot that delete + add = update.
This also means that during regrading, we have to pass around some extra
ids so that new steps know the id of the step they are replacing.
Naturally, this requires some quite trickly logic, so I finally got
around to writing unit tests for question_engine_unit_of_work, which is
a good thing.
Along the way I also got around to renaming
question_attempt->set_number_in_usage, which got missed out when
everthing else was renamed to slot ages ago.
Finally, while working on this code, I noticed and fixed some PHPdoc
comments.
This was one of those innocent seeming issues where, once you start
digging, you find a mess. In this case, the code that is now in
question_wizard_form::add_hidden_fields used to exist in four different
places, in four inconsistent versions. This is now all nicely
re-factored, and that solves the problem.
Along the way, I found and fixed some wrong string references in
qtype_random, and stripped out some unnecessary &s in function
declarations.
