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.