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.
When shortanswer, numerical, calculated and calculatedsimple questions
did not have a '*' match-anything answer, then any student response that
did not match any of the teacher-given answers were classified as
'[No response]', which was not right.
This patch fixes that. Such responses are now classified as
[Did not match any answer].
While I was doing this, I noticed that the display of tolerance
intervals for numerical questions in the response analysis was horrible,
so I improved it.
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.
Eloy Lafuente (stronk7)