Enrolment plugins 2.0

Log of a Jabber chat between Petr and Tim on 6th November 2008.

[18:07:37] Petr Škoda: hi
[18:08:09] Tim: Hi
[18:08:36] Petr Škoda: just wanted to thank you for working on roles improvements, please do not take my comments personally 
[18:08:41] Tim: I am just trying to remove all references to $course->teachers and $course->student, etc.
[18:08:45] Tim: 
[18:08:46] Petr Škoda: great!
[18:08:59] Tim: There are over 100
[18:09:02] Tim: Still
[18:09:07] Tim: Well, down to about 50
[18:09:29] Petr Škoda: could we do something about those enrolments in early december?
[18:09:51] Tim: I was not taking your comments personally. I was just getting frustrated and taking it out on you.
[18:10:09] Petr Škoda: imagine my frustration around 1.7dev
[18:10:13] Tim: Well, it does get annoying when you tell people not to do something, because you are going to do something else later.
[18:10:26] Petr Škoda: yes I know
[18:10:29] Petr Škoda: 
[18:10:32] Tim: You can't rewrite the whole of Moodle on your own.
[18:10:52] Tim: You have to accept that other people will do some things, and they may do it differently from how you woudl do it.
[18:11:44] Petr Škoda: we had a little quarrel around 1.7 with martin - we ended up with unsolved enrolments and tons of role hacks which had to be introduced over the years
[18:12:48] Tim: I think the solution is three separate capabilities: course:view, course:participant and course:gradedparticipant
[18:12:54] Tim: view is for guests.
[18:13:10] Petr Škoda: I do not think only capabilities can solve it 
[18:13:11] Tim: gradedparticipant replaces the gradebookroles setting.
[18:13:24] Tim: Well, you keep saying that, but you have not explained why.
[18:13:35] Tim: What use cases can it not cope with.
[18:13:49] Tim: Actually, the place to start is a list of use cases, so we can agree which problem we are trying to solve.
[18:13:49] Petr Škoda: 1/ that tree structure with overrides is horribly slow if you need to query it
[18:13:59] Tim: Is that still true?
[18:14:23] Petr Škoda: 2/ it can not define temporary access or time limited acces without unenrolling
[18:14:39] Petr Škoda: unenrolling == lost data
[18:15:00] Tim: It is very flexible. It is a trade off of slowness for flexibility. It is not clear to me that our current trade-off is wrong.
[18:15:11] Tim: What data do you lose when you unenrol?
[18:15:21] Tim: You don't lose quiz data, for example. Nor forum posts.
[18:15:26] Petr Škoda: 3/ enrolments need to store more  info related to enrolment - role_assing does not have room for that
[18:15:43] Tim: Again, I ask, what extra information?
[18:15:48] Petr Škoda: you loose grades, forum subscripts - anything that other students can not see
[18:16:04] Tim: YOu don't lose grades!
[18:16:19] Tim: I remember investigating exactly that question at the OU.
[18:16:20] Petr Škoda: not visible 
[18:16:44] Tim: Oh, I see. Well some poeple would see that as a feature.
[18:17:07] Tim: In the quiz there is an option to see grades like that. We could add the same in the gradebook.
[18:17:09] Petr Škoda: but the point is ppl want to freeze the course and keep it as backup - you can not do that easily now
[18:17:43] Tim: Again, I don't see why not. Just take a backup.
[18:17:53] Petr Škoda: you would have to separate course:view and course:enter
[18:18:13] Petr Škoda: no backup, they want to access it after the course finishes
[18:18:13] Tim: What do you think those two caps would do?
[18:18:27] Petr Škoda: I do not think caps should do that
[18:18:49] Tim: The OU is doing access after the end of the course by creating a read=only student role in 1.9
[18:18:59] Petr Škoda: I just wanted one nice table which tells you who is member of course and if can enter it + other enrolment info there
[18:19:16] Petr Škoda: yes, that is a good workaround
[18:19:37] Tim: It is not a workaround, it is how roles was designed to work.
[18:20:08] Tim: You did not answer, what enrolment info is there that is not currently in the role_assignments table?
[18:20:47] Petr Škoda: hmm
[18:21:52] Petr Škoda: ok, lets start the other way - enrolments can not work because they store info in course table, if you have multiple plugins they collide very badly tehre, do we agree?
[18:22:34] Petr Škoda: like the cost
[18:22:43] Tim: Sorry, you will have to explain more than that. I don't know how enrolment plugins work.
[18:22:43] Petr Škoda: enrolment period
[18:22:54] Petr Škoda: ah, np
[18:22:57] Petr Škoda: do you have some time?
[18:23:02] Tim: Yes.
[18:23:05] Petr Škoda: great
[18:23:28] Petr Škoda: so, originally there was only one enrolment plugin active in whole site
[18:24:10] Petr Škoda: so somebody decided to place the plugin configuration specific for each cost into course table - we have cost, enrolemnt duration, etc. there
[18:24:17] Petr Škoda: ok?
[18:24:31] Tim: Well, not OK. That is clearly a poor decision.
[18:24:39] Petr Škoda: it gets worse
[18:24:53] Tim: Enrolment plugins should be able to create their own config tables. No real problem there apart from doing the work.
[18:24:56] Tim: OK, go on.
[18:24:57] Petr Škoda: plguins were designed for enrol only studetns
[18:25:29] Tim: Well, yes, but no reason not to improve them so they can do more now.
[18:25:36] Petr Škoda: then came a big revolution around 1.5 - we can select diffrent type of plugin for each course
[18:25:43] Tim: RIght.
[18:26:01] Petr Škoda: after that we could even select multiple plugins in one course and order them somehow
[18:26:23] Petr Škoda: the guest access was completely hardcoded
[18:26:29] Tim: That sounds cool in theory, if it has been thought through properly.
[18:26:50] Petr Škoda: you have two types of guest access in fact - one for real guest user, other for normal registered user who is not enrolled in course
[18:27:10] Tim: Yes. We had problems iwth that at the OU.
[18:27:20] Petr Škoda: you can specify several guest access restrictions
[18:27:28] Tim: Such as ...
[18:27:29] Petr Škoda: ok, then there are passwords:
[18:27:48] Petr Škoda: no guest, anybody, guest with password,
[18:27:56] Petr Škoda: back to passwords
[18:28:10] Tim: SHould passwords now by implemented as a separate enrolment plugin these days?
[18:28:36] Petr Škoda: entering course you amy have:
* guest access
* enrolment to course
* enrolemnt to course through group password
[18:28:53] Petr Škoda: all of this hardcoded and a bit broken in 1.9.x
[18:29:03] Tim: Right, so we must un-hard-code.
[18:29:21] Petr Škoda: now let me describe my idea how should that work from user perspective in 2.0:
[18:29:29] Tim: OK
[18:29:32] Petr Škoda: yes, unhardcode everything
[18:29:57] Petr Škoda: 1/ image you create a new course
[18:30:04] Petr Škoda: 2/ fill in all course details
[18:30:44] Petr Škoda: 3/ next step - select enrolmnt plugin
[18:31:33] Petr Škoda: 4/ fill in missing info not specified yet - role used for assignemnts, cost, timeend, timestart, password, group distribution info
[18:32:22] Petr Škoda: technically each course would create a new plguin instance with own configuration stored independently from course - just linked to it
[18:32:39] Petr Škoda: even guest access would have special plugin
[18:32:51] Petr Škoda: you would just select plugins you want
[18:33:07] Petr Škoda: core would not know anything about guests, password, etc
[18:33:35] Petr Škoda: makes snese?
[18:33:38] Petr Škoda: sense
[18:34:26] Petr Škoda: administrator would enable some plugins and could also preconfigure them (enforce some settings)
[18:34:29] Tim: Yes. Makes a lot of sense. My only concern is how to build a user-interface to make it easy to understand, but the underlying structure sounds good.
[18:34:37] Petr Škoda: hehe
[18:34:39] Petr Škoda: sure
[18:35:04] Petr Škoda: here come the global groups
[18:35:21] Tim: So, as well as assign roles, for doing manual enrolments, you might have a section of the UI: 'Automatic enrolments' ...
[18:35:32] Tim: In there, you would have a number of rules, like
[18:36:08] Tim: 'If a user does not yet have access, and if they know the password, then assign them role X
[18:36:41] Tim: Each of those 'rules' would acutlaly be an assignment plugin, and they woudl have hooks for showing UI for users trying to get into the course.
[18:36:57] Tim: And each rule would be configurable, and there would be a precidence order.
[18:37:21] Tim: I still think that when they have done their thing, they can create role assignments in the background.
[18:37:38] Petr Škoda: ah, yes - it is the way it works now - first is he enrollend, then plugins are asked in order can you enroll him?
[18:38:09] Petr Škoda: if nobody enrolles him, form is displayed asking for info - password, paypal, etc - each plugin than might be able to enroll if given more info
[18:38:39] Tim: Right. Yes, that sounds about right.
[18:39:08] Petr Škoda: so, from this perspective - enrolments seem more important than roles
[18:39:30] Petr Škoda: the role is just one option (mandatory) for course enrolemnt
[18:39:56] Tim: I don't see how you can say that.
[18:40:30] Tim: I don't think we have a clear definition of what it means to be enroled in a course yet.
[18:40:44] Petr Škoda: each enrolment plugin would be enrolling into one role usually
[18:40:55] Tim: My proposed definition is: 'has the capability moodle/course:paticipate'
[18:41:11] Petr Škoda: admin could make teacher enrolemnt plugin and you would manually select who is going to be enrolled this role
[18:41:24] Tim: If you don't have that yet, for a particular course, then enrolment plugins are a way of automatically creating new role assignments, to give you it.
[18:41:46] Petr Škoda: so instead of having the role assingment UI, you would have much simpler enrolemnt plugin UI
[18:42:19] Tim: I would keep the UI for manually assigning roles.
[18:42:34] Tim: But that would be separate from enrolment plugins.
[18:42:41] Petr Škoda: yes sure, in one enrolment plugin, but you could disable it completely and use something else
[18:43:15] Petr Škoda: even now it is a separate enrolment plugin in fact
[18:43:38] Tim: Hmm. admin/role/assign.php is not an enrolment plugin.
[18:43:44] Petr Škoda: it is 
[18:43:53] Tim: I don't know what code is in enrol/manual
[18:43:58] Petr Škoda: called 'manual'
[18:44:31] Petr Škoda: it is in fact UI of manual enrolment plugin
[18:44:52] Tim: Right, but where do I go in my browser to see that?
[18:45:45] Petr Škoda: I think this is confusing ppl - this manual enrolment plugin (part of assign roles) confuses ppl
[18:45:49] Petr Škoda: grr
[18:46:24] Tim: Ah, admin -> course -> enrolments
[18:46:46] Tim: I that internal enrolment?
[18:46:51] Petr Škoda: yes
[18:46:56] Petr Škoda: always enabled
[18:47:02] Petr Škoda: internally called manual I think
[18:47:08] Tim: Right. That sucks.
[18:47:48] Tim: I would say: don't think of admin/roles/assign.php and anything to do with enrolment plugins. It is something separate.
[18:47:54] Petr Škoda: so the idea was to make much stronger emphasis on enrolments instead of roles in UI
[18:48:13] Petr Škoda: no it is connected - it enrolls you into course
[18:48:17] Petr Škoda: grr
[18:48:33] Tim: Yes, it is connected. Enrolment plugins do create role assignments.
[18:48:45] Petr Škoda: yes
[18:49:01] Tim: I need to think of an analagy
[18:49:05] Tim: analogy
[18:49:13] Petr Škoda: and assigning role at course contexts or above (unfortunately) enrolls you into course
[18:49:21] Tim: OK. How about this:
[18:49:49] Tim: The file API is aobut managing files withing Moodle. The repository API is about getting files in.
[18:50:08] Tim: the role assignments and accesslib are like the file api.
[18:50:32] Tim: Enrolment plugins are like repostory plugins. They get things in, but once things are in, they are handled by moodle internally.
[18:50:42] Petr Škoda: hmm, no
[18:50:47] Petr Škoda: enrolments could do much more
[18:51:03] Petr Škoda: let me explain the problem with time limit on enrollments
[18:51:09] Tim: A file that originally came from a repository, moodle remembers that, and can keep things synchronised, but you can still see that file in the course files area.
[18:51:16] Tim: OK
[18:51:35] Petr Škoda: you coded it in a way that if time expires role assignment is removed
[18:52:18] Tim: Actually, I did not code that bit. It has been like that for ages.
[18:52:39] Petr Škoda: other way is to keep the time info in some enrolment table and just block access to course after enrolemnt expires but keep the role at all times - you can not use role if you can not enter course
[18:53:01] Petr Škoda: yes, from the old ages before roles - it ws never proper part of roles
[18:53:05] Tim: Actually, after sam's change (that I am about to check in), it would be easy to change that.
[18:53:36] Petr Škoda: do you see the difference in blocking access x removing ra
[18:53:38] Petr Škoda: ?
[18:53:41] Tim: The role_assignements table has a active flag now. It would be easy to set that back to 0 now, instead of deleting.
[18:53:48] Tim: Yes, I do see the difference.
[18:53:54] Tim: It is about preserving history.
[18:54:03] Petr Škoda: but we need to cleanup the course related tables - we can nto keep user data there forever, right?
[18:54:10] Tim: Right.
[18:54:22] Tim: Also, for performance, it is good to keep role_assignments small.
[18:54:30] Petr Škoda: yes, I am preserving history by leaving the ra there, you are hacking all places to ignore course data
[18:54:38] Petr Škoda: of removed users
[18:55:00] Tim: I don't understand that last bit.
[18:55:01] Petr Škoda: this is the fundamental difference
[18:55:35] Tim: What do you mean aobut ignoring course data?
[18:56:05] Petr Škoda: like what we do in gradebook - if user not memebr of course we do not show his grades
[18:56:23] Tim: That seems very sensible to me. Some people use that fact.
[18:56:44] Petr Škoda: well, another example is group_memebrs
[18:56:58] Petr Škoda: we delete group membership when unenrolling users, right?
[18:57:18] Tim: If we do, I would be inclined to change it.
[18:57:18] Petr Škoda: why?
[18:57:23] Petr Škoda: hehe
[18:57:28] Tim: LOL
[18:57:40] Petr Škoda: no way, it would be horribly slow because you can not find with SQL who is member of course!
[18:58:12] Petr Škoda: we have very nasty hacks in gradebook, there is 0 change to make the same in groups
[18:58:15] Tim: accidentally unenrolling the wrong user, then immediately re-enrolling them should not cause dataloss.
[18:58:23] Petr Škoda: it sure does
[18:58:40] Tim: Right. I am saying that it should not.
[18:58:55] Petr Škoda: if we could find out who is member of course with SQL, it would be EASY - but it is impossible
[18:59:04] Petr Škoda: now
[18:59:30] Tim: There should be a separate tool, or perhaps part of course reset, to delete date belonging to unenrolled users.
[18:59:36] Petr Škoda: that is the reason why we delete group members and keep it synced with enrolled users
[18:59:46] Tim: Right.
[18:59:50] Petr Škoda: yes, I agree, but it does not solve the problem
[19:01:06] Petr Škoda: solutions are:
1/ make it possible to use SQL to find out who is course memebr
2/ do not unassign roles during unenrol if you want to keep users data
[19:01:26] Tim: Well, if the only concern is performance, and simplicity of writing SQL, then we just need to make a new table that caches the results of has_capability('moodle/course:participate') between courses and users. We do not need to fundamentally change how roles works.
[19:01:53] Petr Škoda: yes, that was one possible solution I proposed
[19:02:06] Petr Škoda: much better what we have now
[19:02:15] Petr Škoda: but still is workaround only
[19:02:28] Tim: I don't see why you say that.
[19:03:21] Petr Škoda: it does not solve the frozen courses - no access for students anymore
[19:03:49] Petr Škoda: hmmm
[19:04:12] Petr Škoda: I guess I just do not like this solution much,
[19:04:16] Tim: Ah, I see, the use case is lock all students out, but allow teachers to go in and still look at grades.
[19:04:19] Petr Škoda: but it seems clear we need to do something
[19:04:24] Petr Škoda: yes
[19:04:32] Tim: It is getting late here, and I am getting hungry.
[19:04:48] Petr Škoda: this was just one example - there were several other problems I do not remeber that would be solved by that
[19:04:56] Tim: This has been a really good discussion. I have learned a lot.
[19:05:00] Petr Škoda: np, it was nice to chat with you
[19:05:07] Petr Škoda: thanks a lot!
[19:05:33] Tim: I am inclined to save a log of this chat, and then maybe have a go a writing up my proposal on MoodleDocs for how this should work.
[19:05:40] Tim: Some time soon
[19:05:42] Petr Škoda: sure +10
[19:06:00] Tim: Then you, and other people can pick it apart, and point out the details my proposal does not cover, and we can take it from there.
[19:06:26] Petr Škoda: yes, I gen go trough tracker and dig out all workaround/hacks we did
[19:06:30] Petr Škoda: can
[19:06:31] Petr Škoda: grrr
[19:06:48] Tim: List of related bugs would be good.
[19:06:55] Petr Škoda: yes
[19:08:15] Tim: Do you mind if I dump this chat log somewhere public, like on Moodle Docs?
[19:08:27] Petr Škoda: not at all
[19:08:57] Petr Škoda: let everybody see my typos 
[19:09:09] Petr Škoda: I type really badly when I think at the same time
[19:10:26] Tim: OK, I have made links at https://docs.moodle.org/en/Development:Developer_notes#Core_code and https://docs.moodle.org/en/Roadmap#Administrative_improvements to the page I will write.
[19:10:47] Tim: And I'll put this chat on the corresponding talk page.

And more

[19:13:07] Petr Škoda: I forgot the global groups - it would work live one enrolment plugin too
[19:13:11] Petr Škoda: like
[19:13:47] Petr Škoda: select global groups enrolment plugin in course and you get all group users into course as students
[19:15:53] Tim: Right. And, would it be possible to make an enrolment plugin that enrols people in a role at site level, so you can set things up so that anyone who is a teacher in any course automatically gets a system level role? That would solve some popular feature requests.
[19:16:32] Petr Škoda: why not, it should be flexible enough to make it possible
[19:16:57] Petr Škoda: all limits and hardcoded code removed from enrolment framework
[19:16:59] Tim: So in the new world, enrolment plugins will be able to enrol into any context, not just courses.
[19:18:05] Petr Škoda: well - not sure how to do that - depends how we define course enrolment; looks like you want to assign role if you get enrolled using one plugin in any course, right?
[19:18:37] Petr Škoda: I would prefer to limit enrolments to course level only and - role assignment is possible at any level of course
[19:18:56] Petr Škoda: level of system 
[19:19:33] Petr Škoda: the problem here is that enrolment is tied to require_login() which works only at course level
[19:19:40] Tim: Well, in my view, an enrolment plugin is just a way of automatically creating role assignmentes in certain situations - in which case, in at least some circumstances, for example on cron, you should be able to set them up to assign into any context.
[19:20:02] Tim: RIght, so the interface hooks for things like asking for passwords would probably only work at course level.
[19:20:15] Petr Škoda: in my view enrolment is triggered by require_login() - and mandatory parameter there is $course
[19:20:32] Petr Škoda: yes
[19:20:47] Petr Škoda: but the plugin my assign 10 roles at different contexts to one user
[19:20:55] Petr Škoda: no restrictions there
[19:21:14] Petr Škoda: but is always starts in one specific course
[19:21:29] Petr Škoda: aaah, another example
[19:21:51] Petr Škoda: conditional access to course - based on some completion criteria
[19:22:18] Tim: I think that restriction only needs to apply to enrolment plugins that interact with the user. There is no need to limit the flexibiltiy of enrolment plugins that just do stuff on cron.
[19:22:24] Petr Škoda: you would have a role, but the access to course would be blocked until you finished something - how would you do that without hardcoding?
[19:22:38] Tim: Yes. That is a good question.
[19:22:49] Petr Škoda: yes, sure - cron and sync to other systems is something else
[19:22:58] Petr Škoda: lets solve that separately
[19:23:19] Tim: Are you sure. At the moment that is also done by enrolment plugins.
[19:23:39] Tim: I guess in the new world, we may need to have two different sorts of plugins.
[19:23:54] Tim: One for cron and one for interactive.
[19:24:04] Petr Škoda: if we create new service API we coudl abuse it for sync wit hexternal systems too
[19:24:17] Tim: In that case interactive ones probably are limited to course level only.
[19:24:34] Petr Škoda: makes sense to me
[19:24:52] Petr Škoda: sync plugins should be expected to do crazy stuff
[19:25:19] Petr Škoda: in fact it might be general sync framework - users, groups, grades, enrolment, etc.
[19:25:48] Tim: Yes. That might let us simplify auth plugins a bit too.
[19:25:53] Petr Škoda: yes
[19:26:00] Petr Škoda: less code repetition
[19:27:10] Tim: And a synch plugin would basically just have a single hook that is called on cron and could do anything.
[19:27:18] Petr Škoda: yes
[19:27:53] Tim: But we some things like modules would still get called separately by cron.
[19:28:03] Petr Škoda: we just have to make sure we have all functions that create_user(), delete_user(), create_course() etc.
[19:28:22] Tim: Hmm. The issue is where synch stuff wants to share config with other stuff.
[19:28:27] Petr Škoda: there are some ugly hacks in enrolemnt sync plugins  now
[19:28:31] Petr Škoda: yes
[19:28:58] Tim: Perhpas it should not be completely separate plugins, just a separate but consistent entry point to all plugins.
[19:29:09] Petr Škoda: yes
[19:29:38] Tim: OK, so we get back to Enrol plugins doing stuff on cron, but that is not a big deal, that is just like all plugins.
[19:31:03] Tim: I am not really succeeding in going home here 
[19:31:08] Tim:  can we really stop now please.
[19:31:13] Petr Škoda: sure!
[19:31:14] Petr Škoda: ciao

Notes

If the patch on MDL-13240 gets committed, we may later want to change things again, so instead of an active column on role_assignments, we instead create a separate table role_assignments_inactive, which stores rows where active = 0, and make role_assignments just store active role assignments.

Groups and enrollment

All that is great, but I actually would like to see more about implementing use case 22, about groups enrolling. This is a big usability pain right now. It's a pity that addressing this issue the only thing we get by now is special case solutions only (like groupings or site-wide groups), not some sort of common solution. --Oleg Sychev 06:43, 13 December 2008 (CST)

active/inactive participation and student's course-list

May I stress one of my suggestions I proposed here:

http://moodle.org/mod/forum/discuss.php?d=119588

http://moodle.org/mod/forum/discuss.php?d=118423

>>13. Admin does not want teachers to be able to unenrol students that have been added by the synchronise plugins, but does want them to be able to remove students they have added manually. >>

The students of universities are ADULT, selfconscious and free/indipendent. So they should be able to manage their course list, i.e. the list of courses they are enrolled in, as appearing in their profile, myCourses-Block and myMoodle.

That's why I propose a solution like the one proposed here, to distinguish different states: enrolled/unenrolled and active participation/inactive participation (i.e. sort of alumni status), so that data (grades, posts, uploads, etc.) of enrolled users in the courses are not lost, never lost, until the course is really deleted.

But the students should absolutely be free to manage their own course-list because it grows larger and larger every semester. They should be able to set their courses to be active or inactive, only to manage their links in myCourses-Blocks, in their profile display (active courses: course1, course2, etc. inactive/alumni courses: course88, course99, etc.)

The management of the course-list should NOT be restricted to teachers, first of all because they have a lot of students and courses and have to focus on other duties with their courses. Hiding the courses as of present is not an option to keep data and reduce the course-list of the students.

Rosario