I thought about renaming the class to just plain attempt, but I
acutally think quiz_attempt makes it clearer what this is. Also
not changing the name massively reduces the pain for everyone
updating their code (including me right now!)
Code should just directly use moodle_execption.
Note, some of the existing uses (in web services) were passing a
literal message, not a language string identifier, but I decided
now was not the time to try to fix that.
dirname() is a slow function compared with __DIR__ and using
'/../'. Moodle has a large number of legacy files that are included
each time a page loads and is not able to use an autoloader as it is
functional code. This allows those required includes to perform as
best as possible in this situation.
This is to be consistent with places like forum and book, where if we
have a next link, we also have a previous link.
At the same time I have amended the links/buttons from 'Previous'/'Next'
to 'Previous page'/'Next page' because I think that is clearer.
Also, on the last page of the quiz, I have changed 'Next' to 'Finish
attempt ...' for consistency with the link in the navigation block.
AMOS BEGIN
CPY [navigatenext,mod_assignment],[navigatenext,mod_quiz]
CPY [navigateprevious,mod_assignment],[navigateprevious,mod_quiz]
AMOS END
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.
The summary page was not enforcing the end of the grace period. If the
user had the summary page open, then they coudl still stubmit after the
end of the grace period.
Also, the editing form was not validating that the quiz grace period was
greater than quiz|graceperiodmin in the quiz configuration, and that
should be checked, so I added it.
I fear that processattempt.php is becoming very spaghetti-like with all
the timing rules, it really needs to be refactored, but not 2 weeks
before the 2.3 release. (When refactoring, we really need unit tests for
this.)
Here, we catch all the places where a student might be accessing their
own attempts, and make sure any automatic state transitions that
should happen, do happen, before the student sees the attempt.
The places where we need to check this are view.php, startattempt.php
and processattempt.php.
We do not really need to check attempt.php or summary.php, because if
the student is on one of those pages, the JavaScript timer will
auto-submit when time expires, taking them to processattempt.php,
which will do the acutal work.
We intentionally do not trigger state transition when a teacher is
looking at a student's quiz attemp. We will trigger state transitions
on cron, but that is still to do.
Also, the body of the process_... methods still needs to be written.
This avoids the problem that you cannot send messages in transactions.
It also means that the quiz submission will not be prevented, and the
message will still be sent eventually, if any part of the messaging
system is giving intermittent errors when the student wants to submit
their quiz.
This was implemented by Matt Petro of the University of Wisconsin - Madison Engineering
School and Math Department. Many thanks. Reviewed by and committed by Tim Hunt.
This adds a new Overrides tab to the UI, with sub-tabs Group overrides and User overrides.
Each of those lists all the overrides that currently exist, and lets you manage them and
create more.
When a quiz is being attempted, the override that applies to the current user is combined
with the current quiz settings loaded from the quiz table (normally called $quiz).
If there are both user and group overrides, then just the specific user override is used (more specific).
If the user is in several groups, then the overrides are combined to give the most permissive set of options.
There is one new database table quiz_overrides, to store the overrides.
