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.
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.
These changes move the logic to the behaviour class, which is how things
should be.
It also makes it easier to re-use the code that displays the messages
like "Marks for this submission: 1.00/1.00. Accounting for previous
tries, this gives 0.33/1.00." in other places.
To try to make it clearer what is going on, I introduced a new class
qbehaviour_adaptive_mark_details to hold and document the data that the
behaviour needs to return, and the renderer can base its display on.
As far as my testing can tell (and there are new unit tests), this
commit does not change the existing behaviour.
This commit also replaces all the string concatenation that is going on,
which should help translators. At the moment, a few of the old strings
are still in the language file, and are used in the unit tests to verify
that the behaviour has not changed.
Thanks to Oleg Sychev for making a helpful suggestion about the API.
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
* Support for old non-standard cron for quiz reports dropped. (Standard
cron support was added in 2.2
* Cron support added for qbehaviour, qformat and quizacces plugins.
* qtypes were already supported in the standard way.
While doing this, I found various bugs in the manages question types admin page, and so fixed them, and updated the code
there to use $OUTPUT and html_writer.
AMOS BEGIN
MOV [cannotdeletemissingqtype,admin],[cannotdeletemissingqtype,question]
MOV [cannotdeleteqtypeinuse,admin],[cannotdeleteqtypeinuse,question]
MOV [cannotdeleteqtypeneeded,admin],[cannotdeleteqtypeneeded,question]
MOV [deleteqtypeareyousure,admin],[deleteqtypeareyousure,question]
MOV [deleteqtypeareyousuremessage,admin],[deleteqtypeareyousuremessage,question]
MOV [deletingqtype,admin],[deletingqtype,question]
MOV [numquestions,admin],[numquestions,question]
MOV [numquestionsandhidden,admin],[numquestionsandhidden,question]
MOV [qtypedeletefiles,admin],[qtypedeletefiles,question]
MOV [uninstallqtype,admin],[uninstallqtype,question]
AMOS END
