View source for Enrolment rewrite and role tweaks proposal

I don't understand this point, could you clarify what you mean: "parental access not supported in require_login() and other parts" --[[User:Dan Poltawski|Dan Poltawski]] 15:48, 22 March 2009 (UTC)


== Why limit enrolment plugins to only assign at course level? ==
This is the big question I have with this proposal. I think we should allow enrolment plugins to assign roles at any context. This will then allow for external systems to help save time in more scenarios. Two examples I am making up:

* All geography teachers having rights to manage the geography category,
* All students of class 11C & 11B being given moderator rights for a forum 

If the teacher can then assign these roles by choosing the global groups rather than individually selecting the students this will be a great advantage, save time etc. Limiting the enrolment plugins to only deal with courses limits a lot of future scenarios where having this facility at any context would be advantageous.
--[[User:Dan Poltawski|Dan Poltawski]] 16:09, 22 March 2009 (UTC)



Good question Dan. After 1.6 anything sticking out of courses was causing major problems in areas like backup, performance, etc. I hope that global groups have a potential to solve majority of issues. I would personally vote for keeping enrolment plugins course only and setting up new different types of plugins. We could also handle roles above course context in auth plugins and use enrolment plugins for course level and bellow. Course participation is a very important concept, I do think we should keep enrolment plugins strictly for this purpose.

* All geography teachers having rights to manage the geography category - might be a synchronisation of global group with role assignments in given course category, maybe we could add a new field which links global group; another possibility is to add this into custom auth plugin
* All students of class 11C & 11B being given moderator rights for a forum - this should be easy with proposed global groups, global groups enrolment plugins would handle course enrolment, role assignments and group membership
--[[User:Petr Škoda (škoďák)|Petr Škoda (škoďák)]] 17:28, 22 March 2009 (UTC)

== Comments from Tim ==

Minor comments:

* I know it is only a detail, but are the savings from using timeend = 2147483647 rather than timeend = 0 (or timeend = NULL) really worth it in course_participant DB table?
** Quick test, SELECT * FROM test WHERE col < 2 does not select rows where col is NULL, so you have to do SELECT * FROM test WHERE col < 2 OR col IS NULL, but that should be quite fast.
* Coding guidelines say it should be course_participants with an s on the end, and the same for other tables.
* enrol_plugin_instance.name, is that really a name, or would calling the column shortname make it clearer what is going on.
* Columns like roleid1, roleid2, customint1, customint2 are really sucky. Much better to do what modules and question types do, where there is a core table with the info that Moodle really needs, then plugins that need more define their own table that joins on.
* If we need to keep the metacourse functionality as it is now, the solution is a metacourse enrolment plugin, that enrols someone on one course if they have a role in another.
* 'New permission evaluation' I still think the is not sufficiently rich to meet all the required use cases.
* I am not sure that moodle/course:inspect is the best name. moodle/course:visit is my alternative suggestion.
* Hidden role assignments not needed - I agree.
* Admin role restrictions - I think we should kill 'doanything' magic cap, and instead user role.archetype == 'admin'.
* I agree with 'Editor' role (although again I am not sure it is the best name. Except, does it need to be different from Course creator?
* I think global group table names should be global_groups and global_group_members.
* 'Role assignment time restrictions moved to course participation table and plugins' - I agree. role_assignments should become a snapshot of the current roles situation only.
* I don't see the need for multiple assignment of the same role in the same context, surely we only need one, even though two plugins are granting it. (are we going to lose role_assignments.enrol column? - ah, no, just change the unique index. That is probably OK.)
* For functions returning complex queries like get_participating_courses_sql, I was wondering if we needed a set of classes for representing SQL queries. That might make it easier to manipulate them in memory, rather than relying on string manipulation.

My big concerns:

* A agree with Dan that enrolment plugins should be able to assign users to any role in any context, if they want to.
** I would like to see a generalised replacement for the 'metacourse' enrolment plugin, that can do things like "Enrol every user who is a teacher in any course as 'Editor' in the system context." - up until now, we have never come up with a satisfactory replacement for is_teacher_any_course - and it would be nice to offer that, and more flexibility.

* Not sure about my second concern, please could you post pseudo-code for what require_login() will look like under this proposal (without caching), so I can think some more.