We have already touched upon enrolment in the introductory chapter, Chapter 3, Courses, Users, and Roles. Now, we will go into more detail and look at the different mechanisms that can be set up to grant users access to courses. You may recall the basic enrolment workflow presented in the earlier chapter. Let's have a look at a more detailed version:
Let's start from the top-left, where the user attempts to access a course. If he/she is already enrolled and the enrolment has not expired yet, he will be granted access. If he/she is suspended, access will be denied. If he/she is not enrolled, Moodle checks whether guest or self enrolment access is allowed. If either is the case, the enrolment key will be checked. If the key is correct or not required, enrolment will take place and access will be granted. Lastly, it is checked if payment is accepted and, if approved, the user will be enrolled to the courses. You might come back to this diagram when we deal with a specific enrolment mechanism.
Students need to be given access to a course before they are allowed to use it. Or, in Moodle-speak, users need to be assigned a role in the course context. They can be assigned the role automatically via cohorts or external enrolment facilities, by self-enrolling, or manually via Users | Enrolled users in the Course administration section in a course.
Granting access is performed via an enrolment mechanism. Moodle supports a wide range of enrolment options, which are discussed in the remainder of the chapter.
The actual enrolment of students does not require administrator rights, and is a task that can be performed by teachers. The role of the administrator is to set up the enrolment mechanisms available site wide.
You can access the course enrolments configuration page via Plugins | Enrolments | Manage enrolment plugins. Each supported enrolment mechanism is represented by an enrolment plugin that can be enabled and configured separately.
For every plugin, the number of instances and enrolments are shown. Each plugin can be enabled or disabled separately, and multiple plugins can be enabled simultaneously (multi-enrolment). The arrangement of plugins determines in which order user enrolments are checked when a user attempts to enter a course. It is recommended to give the plugins, that are used by the majority of users, higher priority over the ones that are only used sporadically as this will benefit system performance.
All the plugins have to be configured; we will deal with these settings when we cover the individual enrolment mechanisms. While it is possible to uninstall plugins, it is not recommended. If they are required at a later stage, they will have to be re-installed. The preference is to simply leave them disabled.
Each enrolment type is now covered in some detail except MNet remote enrolments (Moodle Networking), which is covered in Chapter 16, Moodle Networking and category enrolments, which is a legacy solution and has been replaced by cohort synchronization. The type of enrolment mechanism you choose depends entirely on the infrastructure you have in place, that is, where and in what format learners' data is stored.
Once an enrolment form has been set up, it has to be configured inside the course in which it will be used. Go to Users | Enrolment methods in Course administration, where you will see a list of all the enrolment plugins that are active (shown) and not active (hidden). Each enrolment method comes with a number of settings (except Guest access), which we will cover as part of the plugin itself.
Any non-database enrolment method that has been enabled and configured at site level can be added via the Add method drop-down menu. Whether a plugin automatically appears in the list of new courses depends on the Add instance to new courses parameter. Some plugins, for example, Self enrolment or PayPal, can be added multiple times in the same course, which is useful if you need to support multiple roles.
Moodle supports three types of internal enrolments:
Manual enrolment is the default enrolment mechanism when Moodle is installed. The sitewide settings are set at Plugins | Enrolments | Manual enrolments:
Once the plugin has been set up, you will see a very similar-looking screen under Users | Enrolment methods | Manual enrolments | Edit, in the Course administration section:
The actual enrolment of users takes place in Users | Enrolled users as we have already covered this in the previous chapter. What we haven't covered yet are suspension and expiry of enrolments. You can change these via the edit symbol in the Enrolment methods column of your enrolled course users:
A teacher can carry out all of these steps, but you might decide that these tasks should be carried out centrally for reasons of consistency and also to simplify their workflows. If this is the case, their role has to be modified so that only administrators or dedicated users can deal with enrolments.
If you need to unenrol multiple users from a course, select the Enrol users icon in the Edit column of Enrolment methods where you can select multiple users and remove them from the course.
The concept of self enrolment is relatively simple. Users choose which courses they want to participate in. A course can contain a password, known as the enrolment key. Anyone who knows this key is able to add themselves to a course. An opened-door icon is shown besides courses that allow guest access without a password; a closed-door icon is shown otherwise.
The enrolment key is set at course level. The teacher has to inform the students about the key and ideally limit the enrolment period to an appropriate time frame to avoid any misuse.
Once the enrolment key has been set, learners will have to enter it when they try to access the course for the first time. If the key is entered correctly, access will be granted, otherwise, it will be denied.
The site-wide settings for self enrolments that are found in Plugins | Enrolments | Self enrolment, are as follows:
|
Setting |
Description |
|---|---|
|
Require enrolment key |
If set, new courses must have an enrolment key. Enrolment keys set in the existing courses cannot be removed, but can be modified. |
|
Use password policy |
If set, the password policy (see Chapter 11, Security and Privacy) will be applied to enrolment keys. |
|
Show hint |
If set, the first letter of the enrolment key is shown. |
|
Enrolment expiration action |
This is the action to be taken when a user enrolment expires. |
|
Hour to send enrolment expiry notifications |
This is the time when the enrolment expiry notification will be sent out to the user. |
|
Add instance to new courses |
Every newly-created course will contain this plugin, by default. |
|
Enable existing enrolments |
If set, all the existing enrolments will be suspended and new users cannot enrol. |
|
Allow new enrolments |
If set, new users can enroll to the course. |
|
Use group enrolment keys |
If set, users can self-enrol via a group enrolment key and this also makes them a member in that group. |
|
Default role assignment |
This is the role self-enrolled users will have, by default. |
|
Enrolment duration |
This is the default time for how long users are enrolled in a course. |
|
Notify before enrolment expires |
You can opt to notify only the enroller or the enroller and also the effected user. |
|
Notification threshold |
This is the time before expiration a user will be notified. |
|
Unenrol inactive after |
This is the number of days after users will be unenrolled after they have been logged in to the course. |
|
Max enrolled users |
This is the maximum number of users who can enrol in the course (0 means no limit). |
|
Send course welcome message |
If set, a welcome message will be sent to the user by e-mail. |
Once the plugin has been set up, you will be able to instantiate it at Users | Enrolment methods | Self enrolment inside a course:
You can create multiple instances of the self enrolment method inside a course, which is why you have to assign Custom instance name. This is useful if you need to give different user roles access to the same course, for instance, students and teachers. In addition to the sitewide default settings, you can specify a course Start date and End date as well as Custom welcome message, which will be sent out to newly-enrolled users by e-mail.
Guest access can be seen as temporary enrolment. Users, whether authenticated on the system or not, will be granted controlled (read-only) access to a course. Non-authenticated users will get there via the Login as a guest button on the login screen. Internally, they are being allocated a temporary user ID, which will be disposed of afterward. The guest icon is shown beside courses that allow guest access.
The sitewide settings for guest access are found in Plugins | Enrolments | Guest access:
It is possible to specify a password in the course settings for guest access. If you wish to make this compulsory, select Require guest access password. For newly-created courses, a random password will be generated (unmask the password in the course settings to view it). It will not be possible to remove guest access passwords from courses, but they can be changed.
The Enrolment instance defaults settings are the same as the first two of the manual and self enrolment methods.
The guest access enrolment method can only be allowed or disallowed inside a course. This is done via the Guest access enrolment method where you have to set Allow guest access to Yes and also specify the Password.
Cohorts are sitewide or global groups. Once cohorts have been created and members have been allocated, it is possible to enrol an entire cohort to a course or to synchronize the membership of a cohort with that of a course.
For example, in a school, you might have a class called 7c with 24 students. The same class has to be enrolled in eight different courses, where each course represents a subject. We only have to create the cohort 7c once and then we can enroll all members of that cohort to each course one-by-one. Alternatively, we can activate cohort synchronization with the eight courses, and Moodle will take care of the rest. Also, if a new pupil joins the class, we only have to add his account to the cohort, and the enrolment will be done automatically. Similarly, if a cohort member is removed, the pupil will be unenrolled.
Cohorts are also great for organizations where groups move together between classes, like an elementary school. Instead of moving individual users from one year to the next, you will be dealing with cohorts of users, which is less time-consuming and more fault-tolerant. Cohorts will be covered in detail in Chapter 5, User Management.
The Cohort sync plugin (Plugins | Enrolments | Cohort sync) only contains two parameters—the Default role value that is given to users when they are enrolled and what action to take when users are removed from an external enrolment source, example LDAP:
To see cohort synchronization in action, we have to create a cohort and assign some members to it. Go to Users | Accounts | Cohorts and add a cohort by clicking on the Add new cohort tab. Give the cohort Name (in our case, 7c) and, from the Context drop-down menu, select the category in which all the courses belong to class 7c. Select System, if that doesn't apply. The Cohort ID and Description are optional fields; make sure Visible is checked. Once saved, you have to assign members to the cohort by selecting the Assign icon beside it.
Once this has been successful, we can enrol the cohort (that is, all users of the cohort) to our first course. Inside a course, go to Users | Enrolled users, click on the Enrol users button and select Browse cohorts:
If we select Enrol n users, all n users of the cohort will be enrolled to the course in a way similar to manual enrolment. However, no further synchronization is carried out. It is effectively the same as manually enrolling all 10 users, but in a single step.
An alternative to this one-off exercise is a permanent arrangement where we set up an enrolment method instance via the familiar Enrolment methods link in the course administration section and then add Cohort Sync:
Once added, all users of the cohort will be enrolled and synchronized. Moodle will automatically keep track of the cohort going forward—if a user is added to the cohort, it will also be enrolled to the courses; if a user is removed from the cohort, it will be unenrolled. As with self enrolment, cohort sync allows multiple instances inside a course.
Cohort synchronization is a great way to organize your users if you have groups that have to be enrolled in multiple courses. Whether to use one-off or permanent synchronization depends on the turnover of group members and whether courses have to be kept in sync with those groups.
In larger organizations, it is common to store certain user-related information on a separate database or directory. If this information contains course-related information, it should be utilized for enrolment. In doing so, you minimize the effort that is necessary when using manual enrolment.
Lightweight Directory Access Protocol (LDAP) is an application standard for querying and modifying directory services. It is used by many organizations to store learner details and is therefore, well-suited as an enrolment source for Moodle.
It is necessary that the PHP LDAP extension is installed on the server for the enrolment to work. If it is not installed, Moodle will display an error message. The module supports Microsoft's implementation of LDAP, called Active Directory, as well as OpenLDAP, an open source implementation of the authentication mechanism. It is common for sites that use LDAP enrolment also to use LDAP for authentication, which is discussed in great detail in Chapter 5, User Management.
The principle of the enrolment method is rather simple, but effective. The information stored in the data source about students, teachers, and courses is mapped to the Moodle counterparts. Enrolments are updated when a user logs in. All we have to provide are the mappings.
Moodle makes a number of assumptions when working with LDAP enrolment:
- Your LDAP tree contains groups that map to courses
- Each group has multiple membership entries to map to students
- Users have a valid ID number field
The LDAP settings are located at Plugins | Enrolments | LDAP enrolments. They have been annotated with detailed explanations, hence I will not repeat them; instead, I will provide additional information where applicable. If you are not sure where to locate some of the required information, contact your system administrator.
There are seven sections of parameters that have to be provided:
- The LDAP server settings establish the connection to the directory. LDAP servers with TSL encryption are also supported.
- The Bind settings specify details about the credentials to access the LDAP server, that is, the provided username and password.
- The Role mappings specify how user-related information is stored in the LDAP server. The roles have to be set which contain a context (usually the same as the one in the server settings) and the member attribute (user IDs). It is important to set Search subcontexts correctly. If it is set to No, subcontexts will not be searched, but the search is potentially faster and vice versa. Also make sure that the User type is set to the type of server you use, for example, MS Active Directory.
- The Course enrolment settings specify how course and module information is stored on the LDAP server. It also provides options for different forms of unenrolment.
- The Automatic course creation is a potentially time-saving feature. A course is created for each entry on the LDAP server in the category specified. To expedite the process and to guarantee consistency among courses, you should create a course with the preferred settings and use it (its course ID) as a template for all the newly-created courses.
- The Automatic course update settings lets you specify which fields to update when the CLI script,
enrol/ldap/cli/sync.php, is run. - The Nested groups settings lets you configure support for groups of groups inside your LDAP server.
Working with LDAP enrolments often requires a degree of trial and error. It is recommended to create a number of sample courses and enrolments in a playpen, before applying the mechanism to your production server.
If you need to access multiple LDAP systems with different settings, you will need to duplicate the enrolment plugin at system level and modify the source code accordingly. This task has to be carried out by a programmer as source code changes are required in the copied module.
A lot of organizations use a Management Information System (MIS), either proprietary or developed in-house, that holds information about staff and/or learners and the courses they are enrolled in. It makes perfect sense to utilize this data for enrolment to Moodle. As all the information systems use a database at their core, all we have to do is to get access to the relevant data.
The bad news is that there is a plethora of database systems out there that need to be supported, from the big players such as Oracle and Microsoft SQL Server to the lesser-known systems such as Informix or Sybase. The good news is that there exists a layer called ActiveX Data Objects (ADO), the successor to Open Database Connectivity (ODBC), which does all of the hard work for us. We only have to talk to the ADO layer, and its internals will deal with the rest, no matter what database it is talking to.
The database has to contain course ID and user ID fields. These two fields are compared with fields that you choose in the local course and user tables.
To configure database-driven enrolment, go to Plugins | Enrolments | External database:
The database connection settings have been annotated on the screen with good explanations, which we are not going to repeat here. If you are not sure where to locate some of the required information, contact your database administrator.
For an external database, it is possible to test your settings via the respective link at Plugins | Enrolments | Manage enrolment plugins. The thrown error messages will help you to debug your settings until a valid connection has been established.
Moodle provides a flat file enrolment mechanism that is configured at Plugins | Enrolments | Flat file (CSV). The method will repeatedly (via the Moodle cron process) check for and process a specially-formatted Comma Separated Value (CSV) file in the location that you specify. The format of the file is as follows:
|
Field |
Description |
|---|---|
|
operation |
|
|
role |
See Flat file mapping in the lower part of the same screen, for example, |
|
idnumber (user) |
This is the ID number of the user to be enrolled. It is optional. |
|
idnumber (course) |
This is the ID number of course in which the user is to be enrolled. It is optional |
|
start time/end time |
This is the start/end time in seconds since epoch (January 1, 1970). It is optional. |
The following is a sample file snippet:
add, teacher, 5, Psychology1 add, student, 12, Psychology1 del, student, 17, English2 add, student, 29, English, 1207008000, 1227916800
The start time and end time have to be provided together. To generate the numbers since epoch, it is best to use an online converter.
In the text file settings at Plugins | Enrolments | Flat file (CSV), you have to provide the absolute file location on the server. Moodle has to be able to read the file and delete it once it has been processed!
You can choose to send a log file to the administrator and a notification to the user responsible for enrolments and students. External unenrol action specifies what happens when a user has been removed from the source file. Similarly, Enrolment expiration action specifies what happens to users once their enrolment has expired. The default roles (Flat file having role as mapping) can be overridden with other values, if required:
The IMS Global Learning Consortium has specified an XML file format that represents student and course information. Moodle is capable of using any file that conforms to the format as its enrolment source. Like the flat file format, Moodle checks regularly for its presence and, if found, it will process the file and delete it. You can find details of the basic structure of the format at https://docs.moodle.org/en/IMS_Enterprise.
The plugin is also able to create user accounts if they aren't yet created, or change user details if requested. Furthermore, new courses can also be created if they are not found on Moodle.
All other fields, including role mappings, are self-explanatory. They can be found at Plugins | Enrolments | IMS Enterprise file.
Meta courses are courses that take their enrolment from other courses. They populate many courses from one enrolment, or one course from many enrolments. There are two main scenarios when this is useful, which are as follows:
- Multiple courses want to share information or resources (meta course)
- A course is part of a qualification where students have to be enrolled in a number of courses; each course is set up as a meta course
Both scenarios are depicted in the following diagram:
Go to Plugins | Enrolments | Course meta link. The list contains any roles that are not synchronized, that is, users with those roles in child courses will also be given access to their parent courses. Synchronise all enrolled users means that users will also be enrolled if they do not have a role in any parent courses. External unenrol action specifies what happens when a user has been removed from the external enrolment source, for instance, a CSV file or LDAP. The parameter, Sort course list, determines whether courses are being ordered as specified at Courses | Manage courses and categories (Sort order) or by one of the selected sort criteria.
Teachers have the right to set up meta courses and to manage its dependents via Course meta link under Enrolment method in the Users section of a course. While it is the role of the teacher to manage meta courses, experience has shown that the administrator is frequently asked to set these up on behalf of others.
To set up the first scenario, as shown in the earlier diagram, where the meta course holds shared resources, you have to create all the four courses first and create three separate course meta link instances from within the Computer Science Resources Course. Each instance has to link to a separate child course.
To model the second scenario, you will have to create all 13 courses (one course for MSc Software Engineering and a course for each unit) and add a course meta link method in each of the 12 parent courses to the MSc Software Engineering course.
Meta courses are a great way to synchronize users across courses. There are scenarios where you can achieve the same with cohorts and cohort synchronization. If this is the case, it is usually the preferred option to work with cohorts as they are easier to manage, especially on larger sites.
Moodle comes with a single enrolment plugin that enables you to set up paid courses. There exist other third-party plugins fulfilling the same purpose, but they have not been incorporated into the core Moodle system. Popular examples are Course Merchant (a fully-featured e-commerce service, dedicated to e-learning applications) and Authorize.net (a payment gateway which supports credit card and electronic check payments).
Moodle supports payments for courses, a feature that has been implemented as an enrolment plugin. Simply put, once the payment has been successful, the user will be enrolled in the course.
You have to specify the default cost and currency at site level (Plugins | Enrolments | PayPal).This amount can be overridden in the course. If a course is free of cost, students are not asked to pay for entry. If you enter an enrolment key in the course settings, then students will also have the option to enroll using a key. This is useful if you have a mixture of paying and non-paying learners.
You require a valid PayPal account that can be set up at no cost at https://www.paypal.com/in/webapps/mpp/home (PayPal does take a small percentage of each transaction, though). The notification parameters indicate who is going to be sent an e-mail once a user has enrolled via a PayPal payment. The language encoding has to be set to UTF-8/Unicode in the More Options area of your PayPal account.
Inside a course, you can create multiple instances of PayPal enrolment methods. This allows you to charge different amounts to different user groups/roles or in different currencies.
Moodle has the ability to test the PayPal enrolment mechanism using the PayPal developer sandbox. You will have to add $CFG->usepaypalsandbox to your config.php file (see Appendix, Configuration Settings for details).