Note: You are currently viewing documentation for Moodle 3.11. Up-to-date documentation for the latest stable version of Moodle may be available here: New enrolments in 2.0.

Development:New enrolments in 2.0: Difference between revisions

From MoodleDocs
No edit summary
Line 225: Line 225:


=Enrolment plugins=
=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 - user enrol sync
* two require_login() hooks
* course edit page - plugin settings for each course
* course enrolment methods list - add, remove, hide enrol instances
* management of enrolled users
* cron script


==Manual enrolments==
==Manual enrolments==

Revision as of 22:22, 13 June 2010

Note: This page is a work-in-progress. Feedback and suggested improvements are welcome. Please join the discussion on moodle.org or use the page comments.


Template:Infobox Project Template:Moodle 2.0

Overview

The major difference from 1.6-1.9 enrolments is that the course enrolment information is stored again in a separate database table course_participants. The enrolment related information was move from course table to new enrol table which holds plugin instances. The old enrolment plugins need to be completely rewritten. Course category enrolments via role assignments is not possible any more, existing category enrolments are migrated to new cohorts and cohort enrolment plugin.

The benefits are:

  • we can use SQL to find enrolled users in any course extremely 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 enrolment 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 course_participants 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 plugin configuration data and instance 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 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 int(10) general optional field
customint2 int(10) general optional field
customint3 int(10) general optional field
customint4 int(10) general optional field
customchar1 char(255) general optional field
customchar2 char(255) general optional field
customdec1 decimal general optional field
customdec2 decimal general optional field
customtext1 text general optional field
customtext2 text general optional field
timecreated int(10) timestamp, date when instance created
timemodified int(10) timestamp, date when instance last modified

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 - user enrol sync
  • two require_login() hooks
  • course edit page - plugin settings for each course
  • course enrolment methods list - add, remove, hide enrol instances
  • management of enrolled users
  • cron script

Manual enrolments

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

Temporary guest access

Implemented in /enrol/guest/*. This plugin does not use course_participants table. The course access is granted inside require_login() call together with a temporary guest role. Access key is optional.

Self enrolment

Implemented in /enrol/self/*. Users decide when to enrol. Enrolment key is optional, it can use group enrolment keys too.

Cohort enrolment

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

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.

External database

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

LDAP

TODO - most of the code can be borrowed from database enrol plugin.

Authroize

TODO - luckily we do not need any more hardcoded hooks all over the place ;-)

Flat file

TODO

imsenterprise

TODO

PayPal

TODO - it will be finally possible to set up multiple instances per course, each with different cost&role

MNET

TODO - this needs more internal changes in mnet stuff ...

See also