New enrolments in 2.0

Jump to: navigation, search
New enrolments in 2.0
Project state Implemented
Tracker issue MDL-21782
Discussion n/a
Assignee Petr Škoda (škoďák)

Moodle 2.0


Overview

The major difference from 1.7-1.9 enrolments is that the course enrolment information is stored again in a separate database table user_enrolments. The enrolment related settings were moved from course table to new enrol table which holds plugin instances and their settings. The old enrolment plugins need to be completely rewritten. Course category enrolments via role assignments is not possible any more, for backwards compatibility you can use category enrolment plugin.

The benefits are:

  • we can use SQL to find enrolled users in any course quickly (much better performance)
  • multiple enrolment plugins per course are full supported (includes more instances of the same type)
  • new enrolment overview interface
  • user enrolments may be suspended and reactivated
  • plugin may prevent users to change/break enrolments synchronised with external systems
  • finer access control, more flexible/configurable course settings UI
  • no hardcoded enrolment behaviour - it is possible to completely replace guest access, self enrolments, etc. with custom plugins

Database structure changes

New user_enrolments table

New table which stores users participating in courses (aka enroled users). It can be used directly in SQL joins.

Field Type Default Description
id int(10) auto-incrementing
status int(10) 0 0 means active enrolment, 1 means suspended, anything else means inactive (user can not access course) and is defined by plugin
enrolid int(10) foreign key, references enrol.id
userid int(10) foreign key, references user.id
timestart int(10) 0 time stamp, start of active participation period
timeend int(10) 0 time stamp, end of active participation period
modifierid int(10) last user who modified enrolment, references user.id
timemodified int(10) timestamp, last modification


New enrol table

Stores information about enrolment plugins used in course, includes enrolment instance configuration data and status. The optional fields have plugin specific meanings, plugins may define other tables related via the enrol.id if necessary.

Field Type Default Description
id int(10) auto-incrementing
enrol char(20) enrolment plugin name
status int(10) 0 0 means active plugin, anything else means inactive (user can not access course) and is defined by plugin
courseid int(10) foreign key, references course.id
sortorder int(10) order of instances in course
name char(255) optional plugin instance name, useful when multiple instances of the same plugin are used in course
enrolperiod int(10) 0 optional default enrolment period, in seconds
enrolstartdate int(10) 0 timestamp, optional default enrolment start date
enrolenddate int(10) 0 timestamp, optional default enrolment end date
expirynotify int(1) 0 optional flag
expirythreshold int(10) 0 timestamp, optional
notifyall int(1) 0 optional flag
password char(255) optional enrolment password
cost char(20) optional cost field
currency char(3) optional currency field
roleid int(10) general optional field
customint1-8 int(10) general optional fields (increased in Moodle 2.4)
customchar1-3 char(255) general optional fields
customdec1-2 decimal general optional fields
customtext1-4 text general optional fields (increased in Moodle 2.4)
timecreated int(10) timestamp, date when instance created
timemodified int(10) timestamp, date when instance last modified

Simplified role_assignments table

There is no role assignment duration, it never worked properly for future dates and was not implemented for past dates anyway. The enrol field was renamed to component in order to properly support protected role assignments in auth plugins. The component+itemid is used for protection of each separate enrol instance or auth plugins.

Simplified course table

All enrol related settings were moved into enrol tables. All code that was looking for enrol related info in course table needs to be updated.

Enrolment plugins

Enrolment framework is fully pluggable, there should not be any hardcoded dependencies in code any more. Technically you may delete all enrol plugins and only new custom plugins. Plugins may integrate at:

  • new admin settings pages
  • login process hook - user enrol sync
  • two require_login() hooks
  • enrol page hoop
  • unenrol support hook
  • course edit page - plugin settings for each course
  • course enrolment methods list - add, remove, hide enrol instances
  • course admin navigation hook
  • management of enrolled users
  • cron script
  • etc.

Manual enrolments

Implemented in /enrol/manual/*, true manual enrolments.

Temporary guest access

Implemented in /enrol/guest/*. This plugin does not use user_enrolments table. The course access is granted inside require_login() call together with a temporary guest role. Access key is optional. Course guests can not be members of groups, submit assignments, etc.

Self enrolment

Implemented in /enrol/self/*. Users decide when to enrol. Enrolment key is optional, it can use group enrolment keys too. Since Moodle 2.4 enrolment may be limited to group members, it is possible to specify expiration action and enable expiry notification.

Cohort enrolment

Implemented in /enrol/cohort/*. Synchronises cohort users with course enrolment, optionally assigns group too. The sync is implemented through event listeners.

Category enrolments

Legacy category enrolment plugin which adds enrolment for users with role assignments at course category level. Please note system level role assignment are ignored and you may need to manually enable enrol/category:synchronised capability in all roles that should be synchronised.

Course meta links

Implemented in /enrol/meta/*. Replaces old metacourses. The difference is that every course may be child and parent course at the same time. The sync is implemented through event listeners. It is possible to mix meta enrolments with normal enrolments. Please note that meta enrolments are ignored in synchronisation.

External database

Implemented in /enrol/database/*. Separate course creation and user synchronisation, more sync options are implemented.

LDAP

Implemented in /enrol/ldap/*. Includes course creation and user synchronisation, more sync options are implemented (e.g., nested groups on Active Directory).

Authorize

Luckily we do not need any more hardcoded hooks all over the place ;-) This plugin is not maintained any more.

Flat file

Flatfile enrolments are fully implemented in Moodle 2.5.

IMS Enterprise

This plugin is not dully migrated yet and has multiple serious problems, it is not recommended for any production servers.

PayPal

It is finally possible to set up multiple instances per course, each with different cost&role. Moodle 2.5 includes manual editing and expiration support.

MNET

MNET will be probably deprecated in future Moodle versions.

Upgrade

The data from role assignments table and course table is used to create all necessary entries in enrol and user_enrolments tables. External sync plugins may need to do a full resync. No data is lost during the upgrade, the data from course table is automatically migrated into enrol table records.

Other changes

Course visibility

Originally making category hidden forced hiding of all courses in category. Now the category hiding affects only browsing of courses, not the actual access to courses. When hiding category all courses are hidden automatically, but individual courses can be made accessible later. The new approach improves performance and allows some new scenarios such as hiding of all courses where users are not enrolled in.

See also