Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Quiz access rules: Difference between revisions

From MoodleDocs
 
(2 intermediate revisions by the same user not shown)
Line 30: Line 30:
     backup/moodle2/            - code to backup and restore any data.
     backup/moodle2/            - code to backup and restore any data.
         backup_quizaccess_''name''_subplugin.class.php
         backup_quizaccess_''name''_subplugin.class.php
         restore_quizaccess_''name''_subplugin.class.phpd
         restore_quizaccess_''name''_subplugin.class.php
     tests/*               - Unit tests.
     tests/*                     - Unit tests.


* It is possible to make a working plugin with only the first three of these, but you will probably need more than that.
* It is possible to make a working plugin with only the first three of these, but you will probably need more than that.

Latest revision as of 08:30, 26 February 2014

There are various checks that can be imposed before a student is allowed to attempt the quiz. For example the open and close dates, the time-limit, requiring the student to enter a password before starting, and so on. Since Moodle 2.2, these rules are implemented as a type of sub-plugin.


Overview

Theses sub-plugins have frankenstyle prefix quizaccess_, and live inside mod/quiz/accessrule.

An access rule basically just has to implement one class

class quizaccess_name extends quiz_access_rule_base {

}

The base class is defined in mod/quiz/accessrule/accessrulebase.php documents all the methods you can override. The methods have a default implementation that does nothing, so you only need to override the methods for the hooks you want.

The standard plugins that come with Moodle may not be the best examples to look at, because for historical reasons all their settings are stored in the quiz table. It is probably more helpful to use https://github.com/moodleou/moodle-quizaccess_honestycheck as an example to copy.

The rest of the quiz interacts with the access rules through the quiz_access_manager class defined in mod/quiz/accessmanager.php, The unit tests for all the example rules are worth looking at. The should help you understand what arguments each method takes, and what the return values mean.


What files make up a quiz access rule

mod/quiz/accessrule/name/
    rule.php                    - Contains the implementation of the quizaccess_name class.
    version.php                 - Normal Moodle plugin version.php file.
    lang/en/quizaccess_name.php - Language strings for your plugin.
    db/*                        - lets you define db tables, capabilities, etc.
    backup/moodle2/             - code to backup and restore any data.
        backup_quizaccess_name_subplugin.class.php
        restore_quizaccess_name_subplugin.class.php
    tests/*                     - Unit tests.
  • It is possible to make a working plugin with only the first three of these, but you will probably need more than that.
  • The only lang string that required is 'pluginname'.

Handling settings

If your access rule needs additional settings for each quiz, then you need to:

  • create a database table to store them in using db/install.xml.
  • add the settings to the quiz settings form. Use add_settings_form_fields and/or get_browser_security_choices.
  • save those settings when the quiz form is saved. Use save_settings
  • load the settings efficiently, along with the other quiz data, when a student views the quiz. Use get_settings_sql and get_extra_settings - but try to avoid the second of those for performance reasons.
  • Ensure that the extra settings are backed up and restored, by creating the two files in backup/moodle2. You need to subclass the backup|restore_mod_quiz_access_subplugin classes. These base classes are defined in mod/quiz/backup/moodle2/backup|restore_mod_quiz_access_subplugin.class.php.

https://github.com/moodleou/moodle-quizaccess_honestycheck is a good example of all of this. The standard plugins do not have to do this because their settings are stored in the quiz table (for historical and performance reasons).


When a student view/attempts a quiz

When a student goes into a quiz, we need to create an instance of the quizaccess_name class for each rule that is relevant to this quiz.

Implement the make static factory method to do this. That gets passed the quiz object, which include any extra settings loaded by get_settings_sql or get_extra_settings, and should return an instance of the rule class if the rule is relevant, or return null if it is not.

The description method displays information about the rule on the quiz view.php page. Consider whether this is really necessary. The standard rules provide some good examples of how much information to give.

is_finished reports whether, because of this rule, no more attempts are possible. numattempts is an example of this. delaybetweenattempts is a more subtle example.

The prevent_new_attempt and prevent_access block access to either new attempts or any attempts. They work by returning nothing if access is OK, or returning a list of reasons explaining why if access should be blocked.

is_preflight_check_required, add_preflight_check_form_fields and validate_preflight_check methods are to do with rules like the password or honestycheck that need to present a challenge to the student when they try to attempt the quiz.

notify_preflight_check_passed and current_attempt_finished lets the rule do things when the student starts or finishes attempting the quiz.

time_left is used to initialise the countdown timer during the attempt. The openclosdedate and timelimit rules use this.

attempt_must_be_in_popup, get_popup_options, setup_attempt_page are used by the securewindow rule.

get_superceded_rules lets you make a custom rule that replaces one of the standard ones. There is no example of this yet, but see MDL-13592 for why you might want to use this.

Remember that for more detailed documentation of all these methods, see the PHP docs.

See also