There are serveral ways a quiz attempt can be submitted:
1. The student click the Submit and finish button. In this case,
no problem. We record the current time as the finish time
for the quiz attempt.
2. The student is activly working away at the quiz, and the
count-down timer reachers zero. In this case, we also record
the current time. Note that, if the server is under high load,
then this could well end up being a few seconds after the
theoretical end time, so you could have a quiz with a 30 minute
time limit, with an attempt that lasted 30:07. However, this
is just an accurate reflection of what happened, so should
be recorded like this.
3. If the student is offline when the time expires, then
(depending on the quiz settings) the attempt may be
automatically submitted by cron, but this will happen with
at least some delay (to prevent race conditions between cron
and a student working online) and if cron is running slow
on the server, it could be a lot later. Previously, this led
to, say, a 30 minute quiz where an attempt seemed to have
lasted 67 minutes, which confused people.
Now, in this situation, the finsh time for the quiz attempt is
recorded as the time when the time limit ran out. This is not
just less confusing for teachers looking at the quiz report,
it is also more accurate. That is the latest time at which
students could have made any changes to their responses.
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.
