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.