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.
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.
* Support for old non-standard cron for quiz reports dropped. (Standard
cron support was added in 2.2
* Cron support added for qbehaviour, qformat and quizacces plugins.
* qtypes were already supported in the standard way.
