Working on the LDAP enrolment plugin (against 1.4.1), I realized that the mdl_user_students and mdl_user_teachers tables are not being populated. And their schema doesn't have the fields I'd have expected.
The original plan at http://moodle.com/development/plans/enrollment.html seemed to imply a strategy very similar to the auth plugins.
Is anyone working on this?
Enrolment architecture - plan vs implementation
Number of replies: 11Re: Enrolment architecture - plan vs implementation
Those tables are being populated by enrolment plugins ... what do you mean?
Re: Enrolment architecture - plan vs implementation
Hmmm. Ok, then I am probably doing something wrong here ;)
I've cloned the database enrolment plugin and rewritten the functions following the same structure and conventions. As part of the login process, $user->student _is_ being populated correctly.
I was expecting, however, the base class or the caller function to populate mdl_user_student, and it isn't happening anywhere. The database plugin doesn't seem to do it either. I looked at the paypal plugin and it has it's own additional table. So I reached the conclusion that it wasn't happening as I'd understood.
Also, much like mdl_user's idnumber and auth fields, I expected mdl_user_student to have equivalent fields, and they are nowhere to be seen.
Where should I be looking for the mechanism that populates mdl_user_student, then?
I've cloned the database enrolment plugin and rewritten the functions following the same structure and conventions. As part of the login process, $user->student _is_ being populated correctly.
I was expecting, however, the base class or the caller function to populate mdl_user_student, and it isn't happening anywhere. The database plugin doesn't seem to do it either. I looked at the paypal plugin and it has it's own additional table. So I reached the conclusion that it wasn't happening as I'd understood.
Also, much like mdl_user's idnumber and auth fields, I expected mdl_user_student to have equivalent fields, and they are nowhere to be seen.
Where should I be looking for the mechanism that populates mdl_user_student, then?
Re: Enrolment architecture - plan vs implementation
Looks for the functions enrol_student() and unenrol student() being used around the place.
Also, make sure you are looking at the latest enrol/database/enrol.php from MOODLE_14_STABLE or HEAD, because it had major fixes last week.
Also, make sure you are looking at the latest enrol/database/enrol.php from MOODLE_14_STABLE or HEAD, because it had major fixes last week.
Re: Enrolment architecture - plan vs implementation
Ok, looked at the changes. It now makes more sense ;)
However... there is something I am still uncomfortable about. It seems to me that we still don't have a means of telling "local" enrolments from external enrolments.
Thus the cleanup part will remove 'local' enrolments. The purpose of the LDAP enrolment module I am working on is to allow LDAP enrolments to come from the student management system, but we don't intend to block enrolments (managed by admins/tutors).
However... there is something I am still uncomfortable about. It seems to me that we still don't have a means of telling "local" enrolments from external enrolments.
Thus the cleanup part will remove 'local' enrolments. The purpose of the LDAP enrolment module I am working on is to allow LDAP enrolments to come from the student management system, but we don't intend to block enrolments (managed by admins/tutors).
Re: Enrolment architecture - plan vs implementation
No, that's right. Currently enrolments are just enrolments and can be managed automatically or manually. One headache at a time. 
Re: Enrolment architecture - plan vs implementation
Ok. I had been confused by the fact that some enrolment plugins offer "enrol_allowinternal".
Would it be a bad thing to add to the architecture at this stage? The LDAP module as I've got it running now seems to be doing it, but I'm still testing.
Would it be a bad thing to add to the architecture at this stage? The LDAP module as I've got it running now seems to be doing it, but I'm still testing.
Re: Enrolment architecture - plan vs implementation
Well, all the enrolments stuff is pretty new as you know so it could use some testing and thinking and polishing ... How should it work?
Should external enrolments be restricted so that a teacher is prevented from unenrolling that person manually?
Should internal enrolments be protected so that the external enrolment mechanism can't touch them?
What happens if a manual enrolment was made and the external enrolment changes to reflect this too ... is it internal or external?
Should external enrolments be restricted so that a teacher is prevented from unenrolling that person manually?
Should internal enrolments be protected so that the external enrolment mechanism can't touch them?
What happens if a manual enrolment was made and the external enrolment changes to reflect this too ... is it internal or external?
Re: Enrolment architecture - plan vs implementation
Martin, is it safe to loop over an array while unsetting its values? As far as I can tell, unset() will reset all the internal "magical" pointers of an associative array. And magical foreach mechanisms will start acting silly.
Even if it doesn't it is a hazy area, I would not count on PHP doing the right thing in such a case.
Currently, in enrol/database/enrol.php we have code that does:
foreach ($user->student as $courseid=>$value){
...
if (something I don't like){
unset( $user->student[$courseid] );
}
...
}
Given that we are not using $value at all, I am replacing such loops in my code (enrol/ldap/enrol.php) with something along the lines of
$courses = array_keys($user->student);
foreach ($courses as $courseid){
// now I can mess $user->student without messing my loop
}
Even if it doesn't it is a hazy area, I would not count on PHP doing the right thing in such a case.
Currently, in enrol/database/enrol.php we have code that does:
foreach ($user->student as $courseid=>$value){
...
if (something I don't like){
unset( $user->student[$courseid] );
}
...
}
Given that we are not using $value at all, I am replacing such loops in my code (enrol/ldap/enrol.php) with something along the lines of
$courses = array_keys($user->student);
foreach ($courses as $courseid){
// now I can mess $user->student without messing my loop
}
Re: Enrolment architecture - plan vs implementation
foreach operates on a copy of the original array (with it's own pointer) so it should be fine (I've used this in many places and never had a problem with it).
However, you're right that some of the documentation is a bit hazy on this, and if someone were to extend such a loop with other array functions in there without knowing about these issues then it could lead to bugs in that new code. In that case making your own copy as you suggest is probably a good idea for overall robustness.
However, you're right that some of the documentation is a bit hazy on this, and if someone were to extend such a loop with other array functions in there without knowing about these issues then it could lead to bugs in that new code. In that case making your own copy as you suggest is probably a good idea for overall robustness.
Re: Enrolment architecture - plan vs implementation
I was hoping to use moodle for some extra-curricula postgrad courses that will only allow a certain number (variable) of people. Is it possible to restrict numbers enrolling for a course?
I developed a system previously, but it needs revamping. My previous system had a waiting list functionality - I don't suppose Moodle has any modules with this in mind?
Thanks,
Paolo
I developed a system previously, but it needs revamping. My previous system had a waiting list functionality - I don't suppose Moodle has any modules with this in mind?
Thanks,
Paolo
Re: Enrolment architecture - plan vs implementation
This is exactly the feature I am looking for as well. We would be interested in collaborating to implement this feature if it has not already been done. Please feel free to contact me regarding this at robert.greeley@expert-views.com