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.
MySQL only accepts 65536 (aprox) bytes in default TEXT
columns. So we define the max allowed as 32000 to allow
99.9% of utf-8 contents to fit. If some day MDL-19603 is
implemented and all current TEXTs are moved (MySQL) to
the BIG counterparts, this restriction can be out (MDL-19603).
1. So we will truncate the question summary to 65000 chars if necessary.
2. Also, fix one minor error in mutlianswer save_question_options.
question_bank::MAX_SUMMARY_LENGTH is not the most logical class to add
the constant to, but it needs to be accessible during upgrade, so I was
lazy and put it there.
This commit also includes a lot of useful tidying up of some of the unit
test helper code. I turned out that I could not use all the helper code
in my new tests, but despite that it will be useful in the future, so I
am committing it here.
There was one place where I had only fixed the backup code to work-around bad data from Moodle 2.0. I needed to make the equivalent change in the upgrade code.
The bad data is that the seq_number fields can be wrong (not unique). Se already have data ordered by (seq_number, id) and the array keys of the array we are building are not used for anything, so this fix deals with the problem.
There were two main problems:
1. The unit tests for upgrading adaptive quiz attempts had slighly the
wrong $expectedqa, and so matching that the upgrade was doing the wrong
thing in certain situations. The main issue was that it was setting
-_try = 1 on the first step, which broke the penalty calculation when
the quiz was regraded. There were also some other subtleties with
incrementing -_try that were not right before.
2. It was possible in 2.0 and earlier for two question_states to get the
same seq_number, and restoring 2.0 backups was rashly assuming that that
was unique.
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
Eloy Lafuente (stronk7)