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
Once the attempt became overdue, it was impossible to get in to submit
it because of a redirect loop. This fix resovles that loop, so the
student can enter their password and get in.
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.
It is only necessary when there are (non-preview) attempts. However,
after making this change we have to ensure users cannot start attempts
when ->grade > 0 and ->sumgrades = 0.
Display ->grade on the order and paging tab of edit.php, so it is clear
what is going on when you are using that tab.
Finally, improve the error message a student gets if they try to start a
quiz with no questions.
This achieves a massive clean-up. It simplifies comples code in a number
of places. It allows some methods and functions to be moved to a more
appropriate home (for example cannot_review_message to the quiz class).
It moves more logic out of the renderer.
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.
MDL-15537 - create oo attemptlib.php to hold shared code between attempt, summary and review.php
MDL-15541 - Refactor starting a new attempt into a new file startattempt.php
MDL-15538 - Rework attempt.php to use attemptlib.php
