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 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 patch adds completion options to Quiz similar to what is available in scorm.
One can have the quiz marked complete when either a passing grade is achieved or
all attempts are used up. This will allow a quiz to complete when the user "passes
or fails". (Where "fail" means "using up all attempts without passing".)
In new logging api, xxx_get_view_actions() and xxx_get_post_actions()
will not be used to identify the paticipation of user. Event's crud
and edulevel status will define user's participation.
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.
Making a quiz visible on the course page, of via the settings form,
could cause the grade item to become visible in the gradebook, even
though the quiz supports FEATURE_CONTROLS_GRADE_VISIBILITY to ensure
that when the grades are hidden in the quiz settings, they do not appear
in the gradebook.
Now, if a module supports FEATURE_CONTROLS_GRADE_VISIBILITY, then
set_coursemodule_visible calls the _grade_item_update callback to update
the grade item(s).
In addition, there was a bug when saving the quiz form, where it used
the value of $cm->visible from the database, which was wrong if the
value of cm->visible had just been changed on the setting form.
* FEATURE_USES_QUESTION_BANK is now a module_supports flag which declares
that an activity uses the question engine.
* question_module_uses_questions can be used to determine if a module
uses the question bank.
This is a followup to MDL-18301. That fix missed the following points:
1. On the edit categories and items screens, all items had an eye-con to
control the visibility, even if the visibility was controlled by the
module.
2. Changing the visibility of a grade category change the visibility of
all items within it, even if the visibility was controlled by the
module.
3. The quiz ingored $cm->visible when controlling whether its grade item
was visible.
This got added during the Moodle 2.0 files API conversion, but was
always part of a failed experiemnt, so should have been deleted
long ago. It was never actually used.
Some message providers have an associated capability. For example
the mod/quiz:emailconfirmsubmission capability. At the moment,
we only show the preferences for the capabilities that the user
has in the system context.
That does not work for the example capability above. Typically
the capability will be overridden in one quiz, to allow for
Students, and the user will have the Student role in the course
context. Therefore, this message type does not appear on the
preferences page.
This fix corrects the logic, so that all message types that are
to the current user are displayed.
The quiz does not really support outcomes, but even so in 1.9 you could
select outcomes on the quiz edit form, and apparently this was useful to
some people, therefore we should re-enable it.
