Latest stable version 1.9.9+

There are 5 trivial commits into the stable branch from the last development week (from Tuesday Jun 15 to Monday Jun 21). David Mudrák (also known as “I” in this blog ) fixed coding error producing PHP notice and improved a check of user context existence in the list of users (c36671d). Helen Foster fixed spelling typo in a Quiz help file, spotted by Stuart Mealor (MDL-22842). Tim Hunt fixed several broken $Id$ CVS tags.

Future version Moodle 2.0 Preview 3

There are 69 commits into the main development branch from the last week. The highlighted one for this week is Sam Hemelryk’s one which adds a new element – colour picker – available for administrator config screens (MDL-22806).

Quotes of the week

“Gentlemen, we have reached a milestone. The download is exactly 1,000,000 bytes. Now we have to get it in the right order.”
– Martin Dougiamas knows the secret of sofware engineering

“We do not need any new API for fetching of course record – we have DML with MUST_EXIST flag which is the right way now; we should not include course/lib.php on each page anyway.”
– Petr Škoda removed get_course_by_id(), get_course_by_idnumber() and get_course_by_shortname() from course/lib.php

Good morning, students, and welcome to the course

On Monday, Petr Škoda committed the enrolments patch he was working on recently. The patch is quite huge – it touches 225 files, removes 7603 lines of code and inserts 11019 lines. You can see the changes nicely at github. This patch was one of the last significant things to be included in Moodle 2.0 release so let us have a closer look at it.
Shortly said, the patch changes the enrolment implementation – that is where and how the information about the users participation in courses is kept. In old Moodle versions (up to 1.6) there used to be two database tables to hold the enrolment information – user_teachers and user_students. Each of these two tables represented a relationship with M:N cardinality between the table user and the table course, with some additional information (the start and end date of the enrolment etc). When Roles and capabilities were introduced in Moodle 1.7, these tables were dropped and the capability moodle/course:view started to control if the user is allowed to participate in the course.
Subsequently, it become clear that the implementation based purely on capabilities is not enough in some real scenarios.

• There is a conceptual difference between “view the course” and “be seen as a course participant”. For example, you want to let school Inspectors to enter the course but nobody should be able to know about them. Therefore, hidden role assignments had to be introduced.
• With the capability, it is pretty difficult – but not impossible – to manually order teachers names at the course information page (you know – all teachers in the course are equal, but some of them are more equal than others).
• Many enrolment related information are kept in the course table and therefore must be shared by all enrolment plugins – for example the start/end dates of the enrolment availability, course cost, enrolment key etc.
• Enrolments are not manageable with system-level groups of users.
• Moodle should support common tasks like enrolling students in advance (so that the administrator can prepare the winter term enrolments during the summer), the enrolment can be temporarily disabled for the student or students should be given read-only access to the course after it has finished. These things are kind of doable in Moodle 1.x, though one could expect quite cleaner and more straight procedures from LMS.

Petr tried to deal with these and many other issues by re-designing the internal enrolment system. In fact, Moodle 2.0 did a small step back to pre-1.7 enrolment ages and now there is again a table to hold the list of all course participants – user_enrolments. This table holds the list of all users that participate in a given course – that is they should be listed as course participants (in most cases, these are good old teachers and students). The enrolment record has its state flag – at the moment it can be ENROL_USER_ACTIVE or ENROL_USER_SUSPENDED. See is_enrolled() function for details.
It must be said that the enrolment itself does not give the user any other privilege but to open the course home page. To submit assignments, post into forums or take a quiz, the user must have appropriate role assigned. Both edge cases are valid – enrolled user without any role (for example a student who finished the course or the learner with outdated subscription) and a user with a permission to visit the course without being considered as enrolled (for example the school headmaster or an inspector from the Minitrue). From the UI perspective, the users from user_enrolments table are called Participants or Enrolled users. The users without the record in the table who have the capability moodle/course:view (typically administrators, managers, inspectors etc) are called Other users.
Yet another big change is that enrolment plugins (that is manual enrolment, LDAP based enrolment, External database, PayPal etc.) now have instances in all courses they are used. All instances of enrolment plugins are registered in the table enrol. This table now contains columns that used to be in the table course. Therefore, every enrolment plugin instance can have its own configuration – like enrolment key, dates, expiry notification settings etc. The database table user_enrolments links the given user with the enrolment plugin instance (which in turn is linked with a course). Every instance is allowed to modify just own data – this helps to prevent situations like when a teacher manually unenrolled a student who was enrolled by an external system and the student got enrolled again during the next synchronisation. This is not allowed any more – one plugin can not modify data of an other one.
From the developer point of view, it is nice that you can get course participants again at SQL level (this was not possible before due to complex permissions algebra). This may rapidly increase the performance of some parts of Moodle.

Post scriptum

My lovely wife won a motor scooter in SMS contest! I may become 50 km/hour pirate of the roads. Yahgrr!