Enrolment plugins
Moodle provides a number of ways of managing course enrolment, called enrolment plugins. Each course can decide its enabled enrolment plugins instances and any enrolment plugin can define a workflow the user must follow in order to enrol in the course.
Course enrolment information is stored in tables enrol, user_enrolments and optionally other custom database tables defined by individual enrolment plugins. By default user enrolments are protected and can not be modified manually by teachers but only via the specific enrolment plugin.
Enrolment gives users following privileges:
- User with active enrolment may enter course, other users need either temporary guest access right or moodle/course:view capability.
- "My courses" shows list of active enrolments for current user.
- Course participation - some activities restrict participation to enrolled users only. The behaviour is defined independently by each activity, for example only enrolled users with submit capability may submit assignments, the capability alone is not enough.
- Only enrolled users may be members of groups.
- Gradebook tracks grades of all enrolled users, visibility of grades is controlled by role membership.
Enrolments and role assignments are separate concepts, you may be enrolled and not have any role and you may have a role in course and not be enrolled. Roles at course context level and below may be controlled by enrolment plugins.
File structure
All enrolment plugin files must be located inside the enrol/pluginname folder.
View an example directory layout for the enrol_pluginname
plugin.
Some of the important files for the format plugintype are described below. See the common plugin files documentation for details of other files which may be useful in your plugin.
lib.php
Global plugin functions
File path: /lib.php
The plugin lib.php must contain the plugin base class.
View example
Enrolment plugins must extend enrol_plugin
base class which is defined at the end of lib/enrollib.php. This base class contains all standard methods to define the plugin workflow.
lang/en/enrol_pluginname.php
Language files
File path: /lang/en/plugintype_pluginname.php
Each plugin must define a set of language strings with, at a minimum, an English translation. These are specified in the plugin's lang/en
directory in a file named after the plugin. For example the LDAP authentication plugin:
// Plugin type: `auth`
// Plugin name: `ldap`
// Frankenstyle plugin name: `auth_ldap`
// Plugin location: `auth/ldap`
// Language string location: `auth/ldap/lang/en/auth_ldap.php`
Every plugin must define the name of the plugin, or its pluginname
.
The get_string
API can be used to translate a string identifier back into a translated string.
get_string('pluginname', '[plugintype]_[pluginname]');
- See the String API documentation for more information on language files.
View example
db/access.php
Plugin capabilities
File path: /db/access.php
The db/access.php
file contains the initial configuration for a plugin's access control rules.
Access control is handled in Moodle by the use of Roles, and Capabilities. You can read more about these in the Access API documentation.
If you make changes to the initial configuration of existing access control rules, these will only take effect for new installations of your plugin. Any existing installation will not be updated with the latest configuration.
Updating existing capability configuration for an installed site is not recommended as it may have already been modified by an administrator.
View example
Depending on the enrolment workflow, the access.php file should define the following capabilities:
- enrol/xxx:enrol - used when
enrol_plugin::allow_enrol()
returns true. - enrol/xxx:unenrol - used when
enrol_plugin::allow_unenrol()
orenrol_plugin::allow_unenrol_user()
returns true. - enrol/xxx:manage - used when
enrol_plugin::allow_manage()
returns true. - enrol/xxx:unenrolself - used when plugin support self-unenrolment.
- enrol/xxx:config - used when plugin allows user to modify instance properties. Automatic synchronisation plugins do not usually need this capability.
See enrolment API methods for more information.
version.php
Version metadata
File path: /version.php
The version.php contains metadata about the plugin.
It is used during the installation and upgrade of the plugin.
This file contains metadata used to describe the plugin, and includes information such as:
- the version number
- a list of dependencies
- the minimum Moodle version required
- maturity of the plugin
View example
User enrolment process
Manual enrolment plugins are the simplest way to handle user enrolments. In the core enrol_manual, users with necessary permissions may enrol or unenrol users manually. In the enrol_flatfile plugin allows automation of enrolment and unenrolment actions.
Fully automatic plugins are configured at the system level, they synchronise user enrolments with information stored in external systems (for example enrol_ldap, enrol_database and enrol_category). Some non-interactive plugins may require configuration of enrolment instances (for example enrol_cohort).
Interactive enrolment plugins require user interaction during enrolment (for example: enrol_self and enrol_fee). These plugins need to override enrol_plugin::show_enrolme_link()
, enrol_plugin::enrol_page_hook()
and to implement adding and editing of enrol instance.
Enrolment expiration and suspending
User has active enrolment if all following conditions are met:
- User has record in
user_enrolments
table, - User enrolment already started,
- User enrolment is not past timeend,
- User enrolment has active status,
- Enrol instance has active status in
enrol
table, - Enrol plugin is enabled.
Most synchronisation plugins include a setting called External unenrol action. It is used to decide what happens when previously enrolled user is not supposed to be enrolled any more. Enrol plugins can provide schedulled tasks to synchronize enrolments.
Plugins that set timeend
in user_enrolments
table may want to specify expiration action and optional expiration notification using enrol_plugin::process_expirations()
and enrol_plugin::send_expiry_notifications()
methods.
Enrolment API methods.
Each enrolment plugin can define the enrolment workflow by overriding some of the enrol_plugin
methods.
enrol_plugin::get_user_enrolment_actions(): array
By default, all enrolment plugins will have editing enrolment and user unenrolment actions. However, some plugins may override this method to add extra actions.
View example
enrol_plugin::allow_unenrol(): bool
This method returns true if other code allowed to unenrol everybody from one instance. This method is used on course reset and manual unenrol.
The unenrol action will allow resetif all following conditions are met:
- The method
enrol_plugin::allow_unenrol()
returns true - The current user has the
enrol/pluginname:unenrol
capability.
View example
enrol_plugin::allow_unenrol_user(): bool
This method returns true if other code allowed to unenrol a specific user from one instance.
If allow_unenrol_user
is not overridden, the default behaviour is to call allow_unenrol()
method.
The unenrol action will be displayed if all following conditions are met:
- The method
enrol_plugin::allow_unenrol_user()
returns true - The current user has the
enrol/pluginname:unenrol
capability.
View example
It is quite common in enrolment plugins to allow unenrol only if the user enrolment is suspended (for example: enrol_database, enrol_flatfile, enrol_meta).
View suspended enrolment example
enrol_plugin::allow_enrol(): bool
Define if the enrol plugin is compatible with manual enrolments.
The edit manual enrolment action will be displayed if if all following conditions are met:
- The method
enrol_plugin::allow_enrol()
returns true - The current user has the
enrol/pluginname:enrol
capability.
View example
enrol_plugin::enrol_user()
This method is the plugin enrolment hook. It will be called when user is enrolled in the course using one of the plugin instances. It is used to alter the enrolment data (for example altering the dates or the role) and also to throw exceptions if some external condions are not met.
View example
enrol_plugin:allow_manage(): bool
Return true if plugin allows manual modification of user enrolments from other code. False is usually returned from plugins that synchronise data with external systems, otherwise the manual changes would be reverted immediately upon synchronisation.
The edit enrolment action in the participants list will be displayed if if all following conditions are met:
- The method
allow_manage
returns true - The current user has the
enrol/pluginname:manage
capability.
View example
enrol_plugin::roles_protected(): bool
Enrolment plugins can protect roles from being modified by any other plugin. Returning false will allow users to remove all roles assigned by this plugin. By default, this method returns true.
:::
View example
enrol_plugin:find_instance(): stdClass
Returns enrolment instance in a given course matching provided data. If enrol plugin implements this method, then it is supported in CSV course upload.
So far following enrol plugins implement this method: enrol_manual, enrol_self, enrol_guest, enrol_cohort.
Method must be capable to uniquely identify instance in a course using provided data in order to implement this method. For example, enrol_cohort uses
cohortID
together with roleID
to identify instance. For some methods (like enrol_lti or enrol_payment) it is not possible
to uniquely identify instance in a course using provided data, so such methods will not be supported in CSV course upload.
The only exception is enrol_self - although it is not possible to uniquely identify enrolment instance in a course using provided data, it is still supported in CSV course upload. For enrol_self method find_instance()
returns the first available enrolment instance in a course.
View example
Standard Editing UI
Moodle participants page has a standard editing UI for manual enrolments. To integrate a plugin into the start UI you need to implement the following methods:
enrol_plugin::use_standard_editing_ui()
enrol_plugin::edit_instance_form()
enrol_plugin::edit_instance_validation()
enrol_plugin::can_add_instance()
enrol_plugin::add_instance()
This means that the following functions from the plugin will be called to build the add/edit form, perform validation of the data and add standard navigation links to the manage enrolments page and course navigation.
View example
Sending a welcome email
Some enrol methods has the support for sending welcome mesages to users. To grant the enrol messages are consistent acorrs enrolments methods, the enrol API provides the enrol_send_welcome_email_options
function. This method returns a list of all possible options for sending welcome email when the user enrol in a course and each option has a respective constant defined on enrollib.php:
define('ENROL_DO_NOT_SEND_EMAIL', 0); // Do not send the welcome email.
define('ENROL_SEND_EMAIL_FROM_COURSE_CONTACT', 1); // Send welcome email from course contact.
define('ENROL_SEND_EMAIL_FROM_KEY_HOLDER', 2); // Send welcome email from course key holder.
define('ENROL_SEND_EMAIL_FROM_NOREPLY', 3); // Send welcome email from no reply.