This adds cron code which looks for question previews that have not been
touched for more than 24 hours, and deletes them.
We try to delete previews immediately. For example if the user clicks
start again, then we immediately delete their previous preview. However,
we can't do that if they just close the preview window. Hence we need
some cron code to clean up old preview that have got left lying around.
Normally, this code will not have much to do, so it will be very fast,
so we can afford to run it every cron.
This has been implemented in such a way that in future it will be easy
to add other cron code to the question bank.
Sadly, to make this work on MySQL, we require a horrible hack in the
already hacky delete_usage_records_for_mysql function.
Users should only be able to access their own quetion preview. In the
past, for reasons I can no longer remember, this was enforced
using the session. It is much better to set the question_usage to belong
to the user's context.
In the case where either a question_attempt had not steps, or a
question_usage had not question_attempts, the load_from_records methods
could get stuck in an infinite loop.
This fix ensures that does not happen, with unit tests to verify it. At
the same time, I noticed an error in the existing tests, which this
patch fixes.
The test data was wrong, and was triggering the work-around code that
MDL-32062 introduced. I fixed the test data.
Also, I fixed one of the tests, that had been broken.
The code to upgrade attempts from before Moodle 2.0 to 2.1 created
attempt data that was not exactly the same as a new attempt created in
2.1+. This did not matter very much - revew and the quiz reports all
worked OK - but it broke on re-grade.
These changes detect the problem data in the re-grade code, an apply a
work-around so that the re-grade gives the correct result.
Three things:
1. Fixes to select expectation.
2. Fixes to match walkthrough tests (No idea how these managed to pass
under Simpletest!)
3. Fix expected values for multianswer upgrade tests.
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
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 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.
