Development:New enrolments in 2.0: Difference between revisions
No edit summary |
David Mudrak (talk | contribs) m (Text replacement - "class="nicetable"" to "class="wikitable"") |
||
| (21 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
{{Infobox Project | {{Infobox Project | ||
|name = New enrolments in 2.0 | |name = New enrolments in 2.0 | ||
|state = | |state = Implemented | ||
|tracker = MDL-21782 | |tracker = MDL-21782 | ||
|discussion = n/a | |discussion = n/a | ||
| Line 10: | Line 9: | ||
=Overview= | =Overview= | ||
The major difference from 1.6-1.9 enrolments is that the course enrolment information is stored again in a separate database table '' | The major difference from 1.6-1.9 enrolments is that the course enrolment information is stored again in a separate database table ''user_enrolments''. 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: | The benefits are: | ||
| Line 21: | Line 20: | ||
* no hardcoded enrolment behaviour - it is possible to completely replace guest access, self enrolments, etc. with custom plugins | * 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. | |||
{| class="wikitable" | |||
! 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. | |||
{| class="wikitable" | |||
! 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 | |||
|} | |||
==Simplified role_assignments table== | |||
No role assignment duration, it could never work 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 info 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. | |||
==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== | |||
Implemented in /enrol/ldap/*. Includes course creation and user synchronisation, more sync options implemented (e.g., nested groups on Active Directory). | |||
==Authorize== | |||
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 ... | |||
=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. | |||
=Other changes= | |||
==Course visibility== | |||
Originally making category hidden forced hiding of course category. Now the category hiding affects only browsing of course, not the actual access. When hiding category all courses are hidden automatically. The new approach improves performance and allows some new scenarios such as hide all courses you are not enrolled in. | |||
=See also= | =See also= | ||
| Line 27: | Line 290: | ||
* [[Development:Role archetypes]] | * [[Development:Role archetypes]] | ||
* [[Development:New permissions evaluation in 2.0]] | * [[Development:New permissions evaluation in 2.0]] | ||
* [[Obsolete:Enrolment rewrite and role tweaks proposal]] | |||
[[Category:Developer]] | |||
[[Category:Enrolment]] | |||
[[Category:Roles]] | |||
Latest revision as of 13:23, 14 July 2021
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 user_enrolments. 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 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 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 |
Simplified role_assignments table
No role assignment duration, it could never work 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 info 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.
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
Implemented in /enrol/ldap/*. Includes course creation and user synchronisation, more sync options implemented (e.g., nested groups on Active Directory).
Authorize
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 ...
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.
Other changes
Course visibility
Originally making category hidden forced hiding of course category. Now the category hiding affects only browsing of course, not the actual access. When hiding category all courses are hidden automatically. The new approach improves performance and allows some new scenarios such as hide all courses you are not enrolled in.
