Mostra la font per a Conditional activities Adding module support

{{Moodle_2.0}}

Modules do not need to be changed to support conditional availability, but they do need changing to support the completion system. 

If you make no changes to a module whatsoever, it can only support 'manual' completion (where the user ticks a box).

== Feature support ==

To support the completion system, your module must include a ''modulename''<tt>_supports</tt> function in its <tt>lib.php</tt>. Here is an example:

 /**
  * Indicates API features that the forum supports.
  *
  * @param string $feature
  * @return mixed True if yes (some features may use other values)
  */
 function forum_supports($feature) {
     switch($feature) {
         case FEATURE_COMPLETION_TRACKS_VIEWS: return true;
         case FEATURE_COMPLETION_HAS_RULES: return true;
         default: return null;
     }
 }

The relevant features for completion are:

* '''FEATURE_COMPLETION_TRACKS_VIEWS''' - the module can support completion 'on view', meaning that an activity becomes marked complete as soon as a user clicks on it.

* '''FEATURE_GRADE_HAS_GRADE''' - the module provides (or may provide, depending on settings) a grade for students. When a module supports grades, it can support completion 'on grade', meaning that an activity becomes marked complete as soon as a user is assigned a grade.

* '''FEATURE_COMPLETION_HAS_RULES''' - the module has custom completion rules.

== Completion on view ==

Completion on view means that, if selected, an activity is marked complete as soon as the user views it. 'View' is usually defined as seeing the module's main page; if you click on the activity, and there isn't an error, you have probably viewed it. However it is up to each module precisely how they define 'view'.

=== How to implement ===

In your module's ''modulename''<tt>_supports</tt> function, return true for FEATURE_COMPLETION_TRACKS_VIEWS.

Then add this code to run whenever a user successfully views the activity (for example, just before the <tt>$OUTPUT->footer()</tt> call in <tt>view.php</tt>):

 $completion = new completion_info($course);
 $completion->set_module_viewed($cm);

=== Performance issues ===

Calling this method has no significant performance cost if 'on view' completion is not enabled for the activity. If it is enabled, then the performance cost is kept low because the 'viewed' state is cached; it doesn't add a database query to every request.

== Completion on grade ==

Completion on grade means that, if selected, an activity is marked complete as soon as the user receives a grade from that activity.

=== How to implement ===

In your module's _supports function, return true for FEATURE_GRADE_HAS_GRADE. No other action is necessary.

=== Performance issues ===

When 'on grade' completion is enabled, there will be some additional database queries after a grade is assigned or changed. Unless your activity changes grades very frequently, this is unlikely to be an issue.

== Custom completion rules ==

Custom completion rules allow for module-specific conditions. For example, the forum has custom rules so that you can make it mark a user completed when they make a certain number of posts to the forum.

It is a lot harder to implement custom completion rules than it is to use the system-provided 'view' or 'grade' conditions, but the instructions below should help make it clear.

=== Implementation overview ===

To implement custom completion rules, you need to:

# Return true for FEATURE_COMPLETION_HAS_RULES in your module's _supports function.
# Add database fields to your module's main table to store the custom completion settings.
# Add backup and restore code to back up these fields.
# Add controls to your module's settings form so that users can select the custom rules, altering these database settings.
# Add a function that checks the value of these rules (if set).
# Add code so that whenever the value affecting a rule might change, you inform the completion system.

=== Database fields for completion settings ===

When you provide a custom completion rule for a module, that rule requires data to be stored with each module instance: whether the rule is enabled for that instance, and any options that apply to the rule.

Usually the best place to store this information is your module's main table because:

* The information in the relevant row of this table is likely to be available in most parts of your code, so code changes are minimised.
* You already read this row with most requests, so there is no need for additional database queries which would reduce performance.
* The main table is used for most other module options so it is a logical place for this information.

If you are adding a basic completion condition you probably only need to add one field. To add a field to an existing module, you need to change the install.xml and then the update.php in the same way as adding any other field.

==== Example ====

Throughout this section I am using the forum as an example. The forum provides three completion options but because they all behave the same way, I am only showing one of them.

The forum adds this field to store a completion option:

* '''completionposts''' - this may be 0 or an integer. If it's an integer, say 3, then the user needs to add 3 forum posts (either new discussions or replies) in order for the forum to count as 'completed'.

=== Backup and restore for completion fields ===

Modules do not need to back up the generic completion options, which are handled by the system, but they do need to back up any custom options. You should add backup and restore logic for the fields mentioned above. 

Remember that your restore code should handle the case when these fields are not present, setting the fields to a suitable default value.

==== Example ====

The following code in <tt>backup_forum_stepslib.php</tt> lists the fields to back up:

  $forum = new backup_nested_element('forum', array('id'), array(
            'type', 'name', 'intro', 'introformat',
            'assessed', 'assesstimestart', 'assesstimefinish', 'scale',
            'maxbytes', 'maxattachments', 'forcesubscribe', 'trackingtype',
            'rsstype', 'rssarticles', 'timemodified', 'warnafter',
            'blockafter', 'blockperiod', 'completiondiscussions', 'completionreplies',
            'completionposts'));

As you can see, I added the '''completionposts''' field (and the others that aren't covered in this example) to the list of fields.

=== Form changes for completion settings ===

When you have custom completion conditions, you need to add controls to your module's settings form <tt>mod_form.php</tt> so that users can select these conditions. You can add any necessary controls.

* Implement the <tt>add_completion_rules</tt> function which adds the form controls for your new rules.

* Implement the <tt>completion_rule_enabled</tt> function which is called during form validation to check whether one of your module's completion rules has been selected.

* Implement other form changes if necessary to set up the form with your data. If your data is in the form of simple text boxes or dropdowns then this is not necessary, but you might want to have a checkbox that enables the rule with a separate control to set its value. This needs form tweaks.

==== Example ====

The forum offers a checkbox with a text input box beside it. You tick the checkbox to enable the rule, then type in the desired number of posts.

First, the function that adds these controls:

 function add_completion_rules() {
     $mform =& $this->_form;
 
     $group=array();
     $group[] =& $mform->createElement('checkbox', 'completionpostsenabled', ' ', get_string('completionposts','forum'));
     $group[] =& $mform->createElement('text', 'completionposts', ' ', array('size'=>3));
     $mform->setType('completionposts',PARAM_INT);
     $mform->addGroup($group, 'completionpostsgroup', get_string('completionpostsgroup','forum'), array(' '), false);
     $mform->setHelpButton('completionpostsgroup', array('completion', get_string('completionpostshelp', 'forum'), 'forum'));
     $mform->disabledIf('completionposts','completionpostsenabled','notchecked');
 
     return array('completionpostsgroup');
 }

* The function creates a checkbox and a text input field, which is set to accept only numbers.
* These are grouped together so they appear on the same line, and we add a help button.
* The text input field is disabled if the checkbox isn't ticked.
* Note that this function must return the top-level element associated with the completion rule. (If there are multiple elements, you can return more than one.) 
** This is used so that your controls become disabled if automatic completion is not selected.

Next, a function for checking whether the user selected this option:

 function completion_rule_enabled($data) {
     return (!empty($data['completionpostsenabled']) && $data['completionposts']!=0);
 }

* The custom completion rule is enabled if the 'enabled' checkbox is ticked and the text field value is something other than zero.
** This is used to give an error if the user selects automatic completion, but fails to select any conditions.

That's all the 'required' functions, but we need to add some extra code to support the checkbox behaviour. I overrode get_data so that if there is a value in the edit field, but the checkbox is not ticked, the value counts as zero (the rule will not be enabled):

 function get_data() {
     $data=parent::get_data();
     if(!$data) {
         return false;
     }
     // Turn off completion settings if the checkboxes aren't ticked
     $autocompletion=!empty($data->completion) && $data->completion==COMPLETION_TRACKING_AUTOMATIC;
     if(empty($data->completionpostsenabled) || !$autocompletion) {
         $data->completionposts=0;
     }
     return $data;
 }

Finally, forum already had a <tt>data_preprocessing</tt> function but I added code to this to set up the checkboxes when the form is displayed, and to make the default value of the text fields 1 instead of 0:

 function data_preprocessing(&$default_values){
     // [Existing code, not shown]
 
     // Set up the completion checkboxes which aren't part of standard data.
     // We also make the default value (if you turn on the checkbox) for those
     // numbers to be 1, this will not apply unless checkbox is ticked.
     $default_values['completionpostsenabled']=
         !empty($default_values['completionposts']) ? 1 : 0;
     if(empty($default_values['completionposts'])) {
         $default_values['completionposts']=1;
     }
 }

Phew! That's the form done.

=== Completion state function ===

When you create completion conditions, you need to write a function ''module''<tt>_get_completion_state</tt> that checks the value of those conditions for a particular user. 

The function receives as parameters <tt>$course</tt>, <tt>$cm</tt>, and <tt>$userid</tt> - all self-explanatory, I hope - and <tt>$type</tt>. This has two values: 

* '''COMPLETION_AND''' - if multiple conditions are selected, the user must meet all of them.
* '''COMPLETION_OR''' (not currently used) - if multiple conditions are selected, any one of them is good enough to complete the activity.

Your function should return:

* '''true''' if your custom completion options are enabled and the user meets the conditions.
* '''false''' if your custom completion options are enabled but the user does not yet meet the conditions.
* <tt>$type</tt> (not false!) if none of your custom completion options are not enabled.

==== Example ====

Here's the function for forum (simplified to include only the one completion option):

 /**
  * Obtains the automatic completion state for this forum based on any conditions
  * in forum settings.
  *
  * @param object $course Course
  * @param object $cm Course-module
  * @param int $userid User ID
  * @param bool $type Type of comparison (or/and; can be used as return value if no conditions)
  * @return bool True if completed, false if not, $type if conditions not set.
  */
 function forum_get_completion_state($course,$cm,$userid,$type) {
     global $CFG,$DB;
 
     // Get forum details
     if(!($forum=$DB->get_record('forum',array('id'=>$cm->instance)))) {
         throw new Exception("Can't find forum {$cm->instance}");
     }
 
     // If completion option is enabled, evaluate it and return true/false 
     if($forum->completionposts) {
         return $forum->completionposts <= $DB->get_field_sql("
 SELECT 
     COUNT(1) 
 FROM 
     {forum_posts} fp 
     INNER JOIN {forum_discussions} fd ON fp.discussion=fd.id
 WHERE
     fp.userid=:userid AND fd.forum=:forumid",
             array('userid'=>$userid,'forumid'=>$forum->id));
     } else {
         // Completion option is not enabled so just return $type
         return $type;
     }
 }

=== Notifying the completion system ===

Finally you need to notify the completion system whenever these values might have changed for a user (in the case of the forum example, whenever somebody adds or deletes a post). The completion system will end up calling the function above - but only if it needs to. 

* To ensure performance is not compromised, you should notify the system only when the completion state might actually have changed. Don't notify the system unless your custom completion rule is actually enabled.
* You need to pass in the 'possible result' of the change. This is used to significantly improve performance.  There are three values:
** '''COMPLETION_COMPLETE''' - this change will either have no effect on the user's completion state, or it will make it complete. The change cannot make a user's state ''in''complete if it was complete previously. In the forum example, when you add a post, there is no way this can make the user's state incomplete, so this possible result applies.
** '''COMPLETION_INCOMPLETE''' - this change will either have no effect on the user's completion state, or it will make it incomplete. The change cannot make a user's state complete if it was incomplete previously. Deleting a forum post would fall into this category.
** '''COMPLETION_UNKNOWN''' - this change might have either effect. Using this option is much slower than the others, so try to avoid using it in anything that might happen frequently.
* If the user whose completion state would be updated is not the current user, then the optional <tt>$userid</tt> parameter must be included. For example, if a teacher deletes a student's forum post, then it is the student's completion state which may need updating, not the teacher's.

==== Example ====

Here's the code that runs when somebody makes a new forum post:

 // Update completion state
 $completion=new completion_info($course);
 if($completion->is_enabled($cm) && $forum->completionposts)) {
     $completion->update_state($cm,COMPLETION_COMPLETE);
 }

[[Category:Conditional activities]]