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.
Eric Merrill