Writing your own Trigger Subplugin

For the start, you can also have a look at the implementation of a Dummy Trigger. In the following, we outline what you have to do to implement your own functionality into it.

To create a new trigger subplugin, start with creating a subfolder in the folder trigger. Each trigger subplugin needs some files in order to work. There are some features of the API, which are optional. In the following you will find a description of all available features. The minimal requirements for a working step subplugin are:

• lang file
• lip.php with the functions:
  • check_course(...)
  • get_subpluginname()
• version.php

Functionality of a trigger subplugin

A trigger subplugin has the responsibility to check whether a process should be started for a course. There are two relevant functions for this purpose, which are placed within the lib.php: check_course(...) and get_course_recordset_where(...). Besides this function most of the code described below is boiler plate code, necessary to guarantee the proper functioning of the trigger.

File structure

In the following code segments <yourtrigger> has to be replaced by the name of your subplugin!

db files

A subplugin within Moodle can use all files within the db folder that you already know from a general plugin. This way, you could create a database schema, create event observers of scheduled tasks. However, through the different manager classes offered by the tool_lifecycle API, an own database table is usually not necessary.

lang file

Create a file lang/en/cleanupcoursestrigger_.php containing at least:

$string['pluginname'] = '...';

lib.php

This file contains the logic of your trigger. It contains a class which extends the base_automatic interface, specifying the available API functions. The header of this file should look like:

    namespace tool_lifecycle\trigger;
    use tool_lifecycle\local\response\trigger_response;
    defined('MOODLE_INTERNAL') || die();
    require_once(__DIR__ . '/../lib.php');

    class <yourtrigger> implements base_automatic {

Then, the function check_course($course) has to be implemented. $course represents the returned object of a get_course($id) call. The function can return one of three possible results:

• return trigger_response::next(): This return value tells the core API that the trigger does not want to launch the deprovision process for this course. The API proceeds with asking the next trigger subplugin.
• return trigger_response::exclude(): This return value tells the core API that this course should be excluded from the deprovision process for this course. This is no permanent exclusion. Thus, the trigger plugin is asked every time if this exclusion has changed.
• return trigger_response::trigger(): This return value tells the core API that the deprovision process for this course should be started.

settings.php

A settings.php can be used to define specific settings for the trigger. This file is parsed automatically and appended to the General & Subplugins administration view. You can use the variable $settings to append new settings options. An example for a working settings.php is:

defined('MOODLE_INTERNAL') || die();

require_once(__DIR__ . '/lib.php');

$settings->add(new admin_setting_configduration('cleanupcoursestrigger_startdatedelay_delay',
    get_string('delay', 'cleanupcoursestrigger_startdatedelay'),
    get_string('delay', 'cleanupcoursestrigger_startdatedelay'),`16416000));

version.php

The version.php should contain at least the following values:

defined('MOODLE_INTERNAL') || die;

$plugin->version  = 2017050901;
$plugin->component = 'cleanupcoursestrigger_<yourtrigger>';