Note: You are currently viewing documentation for Moodle 2.0. Up-to-date documentation for the latest stable version is available here: Enrolment rewrite and role tweaks proposal.

Enrolment rewrite and role tweaks proposal

From MoodleDocs

I don't understand this point, could you clarify what you mean: "parental access not supported in require_login() and other parts" --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.

--Dan Poltawski 16:09, 22 March 2009 (UTC)

Add my +1 to having "enrollment plugins" (maybe we should call them role assignment plugins) be able to operate in contexts besides just course. This comes up very often. For example with LDAP integrations users want to assign a global role like Administrator access based on membership in an LDAP group. Others want to automate the cumbersome process of matching user to user roles for parent/student supervisor/employee type relationships. It doesn't matter to me if these are a separate plugin type, but just that we get the functionality which doesn't seem to have quite caught up with the new role system. Another issues is the lack of support for custom profile fields in most of these automation plugins.

--Jonathan Moore 01:11, 1 April 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

--Petr Škoda (škoďák) 17:28, 22 March 2009 (UTC)


Hmm, so let me see if I understand what you are proposing:

  1. A plugin system to populate global groups
  2. A seperate plugin system to populate enrollments
  3. Global groups used as a mechanism to populate groups of role assignments at non-course level

If that is correct, my comments are:

  • How would role assignments related to enrolments in a course be assigned. In the majority of cases a course participant will also want to be assigned the student role. How will this be handled?
  • The enrollment/global group plugins will have *loads* of commonality - it would be good to avoid duplication here. (E.g. ldap plugin might populate a tree of courses, or a tree of groups, but essentially doing the smae here)

--Dan Poltawski 16:51, 24 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.

Proposed additional table field

Hi there,

I realise this may not be possible, but ime of working with my own custom code, when you have a timetable of hundreds of global groups, it is still pretty difficult for staff to find their classes.

What is very useful is to create an association between a moodle user that *teaches* a class and a moodle user that is a *member* of a class. This then allows you to present two lists when enrolling global groups into a course - the full list of all classes and an optional list of that teacher's timetabled `globalgroups`.

So where you have the table `globalgroups_members`, it might be useful to allow a field to be set for 'role'. The default would be 'member', but optionally an enrolment plugin could indicate which Moodle users actually teach that class, perhaps having the value 'owner'. This can then be searched against to find the global groups that a particular `mdl_user` owns, if any, and these can be presented in an optional shorter list. I know my teachers greatly appreciate this functionality.

What do you think? --Dan Ballance 11:23, 24 September 2009 (UTC)

Deleting hidden role assignments needs more work

"Questions and potential problems: Are hidden role assignments used for any other purposes?"

Hidden role assignments often used to grant someone rights to edit course without showing it in the course description (on the main page, in the courses list etc).

Typical use case, which I see very often in our and similar universities:

  • Professor(P) - experienced lector.P has a lot of material on the course, but doesn't like IT and computers and feel bad with internet and moodle (or just don't want manually do all the work on the course creation);
  • Assistant (A) (often post-graduate student, or even simple student) - can work in the Moodle well and dependent from Professor.

Assistant actualy work with Moodle course using materials from Professor. However, as this is official course, Professor badly wants to be mentioned on the front page as it's solely author (editor etc). He doesn't like at all idea of assistant being mentioned there with him, so assistant receives a hidden assignment (he still need role to do the work).

The case is somewhat ridiculous, but it happens quite often and it is very sensitive for the people with lot of influence in the university, so it must be dealed with.--Oleg Sychev 10:10, 27 March 2010 (UTC)

Global groups and metacourses issues

Some possible issues with proposed global groups and removal of metacourses.

The problem with global groups is that they are ... too global. It's never been so in reality: on university site, there are some faculties, and then all those additional educational centers with their own groups, but all those groups need to span multiple courses. Having any group that need to span multiple courses as a global group is inconvenient, but possible. But it really leads to security problems when it comes to assigning: user either could assign people to any global group or to no one. The faculty staff won't like at all having people from other faculty with ability to add (remove even worse) people to their global groups - this can be used for all sorts of dirty tricks. There should be at least some way to give user an ability to manage people only in some global groups.

One common use of metacourses is defining subcourses. It's ideal solution would be global groups + two plugins:

  • module 'subcourse' which represent child course as a graded activity in the parent course;
  • enrollment pluging (probably) that will handle groups and students synchronisation between parent and child courses (there may be a need to have some options there, like having all people in parent course enrolled in child only in certain time interval).

The resulting system would be quite flexible (you could create a parent speciality course, with section for semesters and child courses for actual courses for example, and have all grades in speciality course) and very useful.--Oleg Sychev 10:40, 27 March 2010 (UTC)