Some question behaviours allow the same question to be re-attempted several times during a quiz attempt.
This commit takes care of the case where a "random" question is re-attempted during a quiz attempt.
When selecting the variant of the new question, we need to add the
new question to the usage before trying to select a variant.
Also, we need to acutally use the selected variant number!
1. Don't show a warning if there are a limited number of attempts, only
if there is a time limit.
2. Merge that time-limit warning into the same form that is used for
entering a password, etc.
3. Make that form an JavaScript dialogue when you click the start attempt
button.
AMOS BEGIN
MOV ['confirmstarttimelimit', 'mod_quiz'], ['confirmstart', 'quizaccess_timelimit']
AMOS END
The sections are created on the edit quiz page, and then appear in the
navigation panel when the quiz is being attempted to help students find
their way around.
The 'Shuffle questions' setting has been moved from being per-quiz
to being a per-section.
This commit is actually the joint work of Mahmoud Kassaei and Tim Hunt
from The Open University. We could only use one persons name for the
commit and this time Mahmoud gets the credit/blame.
This feature is designed for use on pracice or formative quizzes.
It is available for quizzes that use Interactive or Immediate feedback
behaviour.
If the teacher turns this on in the quiz settings, then once a student
has finished a question, they get a 'Redo question' button beside the
question. If they click it, then the question they finished is replaced
by a new one so they can try again to practise that particul skill or
bit of knowledge a bit more.
When randomisation is involved, the studnets will be given a question or
variant that they have not seen before if possible.
Further improvements to this code, including resolving edge cases:
* The new feature can only be used when it is possible for the
previous question in the quiz to be complete.
* Also, this new feature cannot be used in combination with shuffle
questions, because that make no sense; nor in combination with
sequential navigation, because to make that work properly would be a lot
of effort. If someone needs that to work later, it should be possible
for them to implement it.
* There were changes in the edit renderer API, to try to make things
more consistent, and to make it less likely we will need to change
things again in the future. See mod/quiz/upgrade.txt.
* As part of this change, the styling of the Edit quiz page was tweaked
to make slighly more efficient use of the horizontal space, and to be
more symmetrical.
If a quiz is set to have a grace period when time has expired, we only
email studnets to warn them about their overdue attempt if they have put
in an answer to at least one question that is worth some marks.
This commit is actually the joint work of Mahmoud Kassaei, Colin
Chambers and Tim Hunt from The Open University. We could only use one
persons name for the commit, and this time Colin gets the credit/blame.
The goal of this work was to increase usability, and also clean up
the page enough that it will be possible to add new features in future.
Display of mod/quiz/edit.php is now entirely generated by
mod_quiz\output\edit_renderer. This uses a helper class
mod_quiz\structure to provide details of the structure of the quiz, and
mod_quiz\repaginate to alter that structure. (Acutally, there are still
some modification methods on mod_quiz\structure. Expect that to be
cleaned up in future.)
The new code uses much more ajax, and there are new scripts
mod/quiz/edit_rest.php and mod/quiz/repaginate.php to handle this.
(Again, don't be surprised if those two scripts get merged in future.)
Also questionbank.ajax.php (which may, in future, be made more generic,
and moved into the core question bank code.)
Most of the new JavaScript code has intentionally copied the way things
are done when editing activities on the course page.
As a result of this, mod/quiz/editlib.php is now much shorter than it
was. (In future, expect the remaining code in here to move into
mod/quiz/classes.)
This change is logically the same as changing
$this->has_capability('mod/quiz:viewreports')
to
$this->has_capability('mod/quiz:viewreports') || $this->has_capability('mod/quiz:preview')
in the original code. However, I rewrote the logic so that we test the
most common and performance-critical case first - that of a student
lookign at their own attempt.
The sequence of questions that made up a quiz used to be stored as a
comma-separated list in quiz.questions. Now the same information is
stored in the rows in the quiz_slots table. This is not just 'better' in
a database design sense, but it allows for the future changes we will
need as we enhance the quiz in the MDL-40987 epic.
Having changed the database structure, all the rest of the code needs to
be changed to account for it, and that is done here.
Note that there are not many unit tests for the changed bit. That is
because as part of MDL-40987 we will be changing the code further, and
we will add unit tests then.
Some columns needed to be renamed:
* quiz -> quizid
* question -> questionid
* grade -> maxmark
Then all the places that refer to those needed to be fixed.
We now compute the average CBM score, accuracy, CBM bonus and enhanced
accuracy, both for the entire quiz, and for just the questions answered.
Note that these calculations must work correctly in the presence of
descriptions, ungraded questions, and manually graded questions. For
example, imagine a essay added at the end of the quiz "Summarise what
you learned attempting this exercise." This might have max mark zero or
non-zero. The CBM statistics just ignores questions like that.
At the top of the quiz reivew page, there is a table that summarises
infomration about the quiz attempt as a whole. For some question
behaviours, we would like to be able to add additional information to
that summary.
This commit introduces a generic method for the behaviour to provide
summary information about an entire question usage.
1. There is a new admin setting to control whether this feature is
enabled. The admin can set the auto-save frequency to 1, 2 or 5 minutes,
or disable it.
2. When autosave is enabled, there is code in the quiz that monitors the
main quiz form, and does an ajax save call at the given frequency when
changes are being made by the student.
3. The ajax saves go to a new script that calls the question engine to
do the work.
4. To avoid simultaneous autosave + submit and finish, the auto-save
system shuts down shortly before time expires in a timed quiz.
It used to be necessary to store the question number and question page
by adding them as random extra fields on the question object (but
I can no longer remember what that reason was). Now it is possible
to store this sensibly in the quiz_attempt object, which is much
cleaner, so do that.
