1. Autosave works in some ways just like a normal save. We ultimately
call $behaviour->process_save() to do the work, and create a new step to
hold the data.
2. However, we come in through a completely different route through the
API, starting with separate auto-save methods. This keeps the auto-save
changes mostly separate, and so reduced the chance of breaking existing
working code.
3. When the time comes to store the auto-save step in the database, we
save it using a negative sequence number.
This is a clever trick that not only distinguises these steps, but also
avoids unique key errors when an auto-save and a real action happen
simultaneously. (There are unit tests for these tricky edge cases.)
4. When we load the data back from the database, most of the time the
auto-save steps are loaded back as if they were a real save, and so the
auto-saved data is used when the question is then rendered.
5. However, before we process another action, we remove the auto-saved
step, so it does not appear in the final history.
1. Split the question_attempt tests into one class per file.
2. Imporve the API to give tests more control, and to test more of the
important code. Some of this is not used here, but it is about to be.
Comment format (FORMAT_...) was correctly being processed when the
manual grading happened as the result of a form submission. It was only
when done using the question_usage or question_attempt API method that
there was no way to specify the format. (Although I think the only place
this API as used was in the unit tests.)
Note that question_attempt::manual_grade API had to change, but I don't
think that is a real API change. Calling code should be using
question_usage::question_attempt, which is backwards compatible.
Note that now, if you don't pass format, then no error is generated, but
a developer debugging message is generated.
This was incorrect use of PARAM_CLEANHTML for these inputs.
This fix also adds some unit tests to try to verify that this does not
break again in future.
This only matters in an obscure edge case, but it is an edge case we hit
with one of the OU question types.
This load data code is processing the results of a LEFT JOIN, so is_null
is the correct logic.
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
