Site-wide groups

Warning: This page is no longer in use. The information contained on the page should NOT be seen as relevant or reliable.

Requirements

Please add concise descriptions of why you need site-wide groups here. There are quite a few different use cases around.

We want to put a whole class of people into a group so that we can easily enrol and unenrol them together from numerous courses. (If people leave that group, should they be unenrolled from the courses?)
We want to present a different theme to each group (with a common login page only). Useful for cases where one site is used by different companies. When combining this with the use of My Moodle then everyone sees just what they want to see, with customised branding etc. Is also useful for giving students a different view from teachers in more places.
We need the ability to display only specific courses for a specific group of users (i.e. clients or project members) due to client- or project-specific content bound by confidentiality and non-disclosure agreements.--Bob Singletary 21:21, 30 January 2009 (CST)
We work a lot with metacourses. In the original (child) courses the members automatically enrol themselves into groups with their group specific enrolment key. It would be great if these groups are also copied to the metacourse. The groupings option makes it possible to unite the same type of groups in one grouping.Flexibility and easy handling would be further enhanced if on site or category level Cohorts ( I like the name) could be defined. A cohort should be assembled from a choice of groups,groupings and individuals. It should not be necessary to build a cohort out of individual participants. Should the Cohort structure be preserved after the import into a course? In this way you create an extra level of aggregation (member- group –grouping – cohort) or should the cohort after import dissolve in the original components? Or should you be free to choose?
Being able to create and populate classes automatically, either from LDAP OUs or via web services Matt Gibson 05:08, 22 January 2009 (CST)
Support for site / category wide groupings. This could remove the confusion and other issues associated with some of the site configuration options where users see too much. This could enable complete separation where required for year groups, clients etc.
Being able to assign activities and resources to these site wide cohorts in the same way that they can assigned to groupings at present would help with teachers managing their courses. Jon Witts 08:15, 5 February 2009 (CST)
Being able to assign a group quickly to many courses at once -- Matt Gibson 03:42, 10 February 2009 (CST)
Being able to message a whole group at once from the messaging interface -- Matt Gibson 05:53, 11 February 2009 (CST)
It would be good to be able to filter groups into categories in the UI (e.g. all English classes filtered together) --Dan Poltawski 16:11, 22 March 2009 (UTC)
I have hacked our 1.9.2 installations in the following way: site-wide groups are created from external system. Some user accounts are identified as teachers, other accounts are mapped to site-wide groups. Teachers then see a list of their groups when they go to enrol students into a course. Enrolling a group is really a batch add user routine. When a group is enrolled it also creates a matching 'local' group so that the groups are visible when marking assignments etc. Teachers no longer enroll individual students. System updates each night, synchronising group memberships with external system.--Dan Ballance 19:04, 18 April 2009 (UTC)
Being able to use the LDAP groups in moodle for enrollment and reporting etc --Daniel Müller 13:46, 8 July 2009 (UTC)
Need to provide training to companies. Would like site wide client/institution grouping (possibly with attached theme) with participants assigned to one or more learning groups within each client/institution. Enrol learning groups in courses instead of individuals. Currently contemplating something like Dan Ballances's hack above - would be useful if moodle modularized to allow greater flexibility for developing solutions for unusual cases. --Paul Shirren 01:49, 2 August 2009 (UTC)

Terms

It might be confusing to think of these as part of the groups systems we have already .... perhaps it's a different complementary system?

Speaking from a school perspective, I tend to use groups in two ways (Matt Gibson 05:06, 22 January 2009 (CST)):

Class groups, reflecting the students physically present in the room when I'm teaching.
Project groups, which are smaller and more temporary, reflecting groups of students who are working on a particular assignment together.

I think 'classes' would be the best term to use for site-wide groups, but I'm not sure what to use for the course level ones.

Do we really need such array of terms: group, grouping, cohort .... what's next? All of them reflects quite similar things. Maybe it is better to have only groups, but groups defined in different contexts (as roles now)? Maby terms not only confuse users, but usually lead to inefficient implementation, with many side-cases. I think it is better to search universal solution (thought it may not be easy), than to add entities without real need. --Oleg Sychev 15:44, 28 January 2009 (CST)

A word of caution here: IME teachers need access to the same site-wide groups as local groups when marking assignments. Say you have 10 maths classes of 20 students each enrolled in a course via site-wide groups. That is 200 students and when teachers come to mark GCSE course work they need a way of navigating these accounts. Filtering the students by local group is very useful here. My hack creates a local group of each site-wide group enrolled in a course so that this is possible and teachers never manually create these local groups. It would be very useful to have an option that switches this on: once switched on then local groups cannot be created manually and are automatically mirrored and synchronized from the site-wide groups enrolled.--Dan Ballance 06:29, 20 September 2009 (UTC)

Possible plans for discussion

Design 1

Martin Dougiamas 02:38, 21 January 2009 (CST)

Let's call them cohorts and keep this separate from existing groups system.
Admin can use an admin interface to define cohorts (with name, icon, description, forced theme, language etc)
Admin can use the admin interface to add users to one or more cohorts (one person could be in Students, First Year Students, and CM3004)
Cohorts are visible in role assignment pages just like people, you can enrol a cohort in a course all with a particular role.
1. A checkbox would allow you to choose whether cohort changes are mirrored as changed enrolments in future (hooked in role_assign and role_unassign)
2. Another checkbox called "Keep this cohort as a group" would create a group with the same name in the course and populate it.
Settings can control whether some people (teachers) can only see users within a particular cohort (eg their own). Useful for when multiple organisations are sharing a Moodle and you don't want useless users appearing in lists.
Enrolment plugins and authentication plugins (eg LDAP) are upgraded to support adding/remove users from cohorts.
The cohort theme beats site theme, but is beaten by user or course themes.

We could do more, but is enough for 99% of requirements?

--David Bogner 05:49, 5 February 2009 (CST) This could turn into lots of work for admins. So following proposition, that enables users to subscribe to cohorts:

A default cohort everyone is subscribed to, (if no other cohort is chosen)
Cohorts you can freely subsribe to as authenticated user (on account creation or later)
Cohorts that require a key to subscribe to
Cohorts users can only be assigned to by admin
Cohorts should be placed in user profile as mandatory field: username email firstname surname cohorts

--Ray Lawrence 11:51, 5 February 2009 (CST)

7. Cohort theme priority: Why fix this? Better to define this for the site as with existing theme types currently.

Cohorts = Groups at contexts higher then course? Groups don't govern visibility of activities, from the above it appears that cohorts would not govern visibility of courses or categories. Without this degree of separation users with access to a cohort may have restricted access to other users but will still see categories, courses which are irrelevant to them. An equivalent of groupings needs to be factored in to the development.

Design 2

John E 10:22, 28 January 2009 (CST)

We've been throwing around some ideas for site level grouping for some things we'd like to achieve and make easier on our end. Below are some of the initial design points we've come up with. Admittedly this is quite complicated and touches a lot of core components, but we're hoping it will lend itself to a lot of flexibility in the long run.

Groups are defined on site level.
Groups qualify as assignable entities on role assignment screens (on any context).
Groups become a context themselves, and roles may be assigned on that. (Ideally to create student/teacher relationships on a site level so the "teacher" may edit or view reports for a student without assigning a site level role to that teacher.)
If a user has a role that allows them to be part of a course, any site level groups they are a part of are accessible and are usable within the course (but are read only?).

Martin Dougiamas 02:36, 3 February 2009 (CST): Re(3) I think it's going to be nearly impossible to have groups be contexts themselves. The calculation of permissions is going to be quite insane since the Design 2 groups can be inside any other given context, perhaps more than once. Especially with groupings as well! Wow.

--John E 13:07, 16 February 2009 (CST): ReRe(3) Understandable. The goal was to assign a mentor/teacher/etc type person into a role so they could manage users within that role outside of being assigned a role within a course. Ideally the roles or permissions to make this happen would not be assigned on site level. Perhaps there is another way to do this? Maybe context ancestry is not taken into account when calculating permissions for the group context? I do see CONTEXT_GROUP in the accesslib, but not really anywhere else, is there any documentation as to the original intention of that context?

Martin Dougiamas 02:36, 3 February 2009 (CST): Re(4) If a single person who is a part of a site-wide group called "Staff" is enrolled in a course, and his site-wide group "Staff" appears as a group in the course, should all the Staff appear in there? Either way could be confusing to the teacher of that course ...

--John E 13:07, 16 February 2009 (CST): ReRe(4) Ideally, if the single user is enrolled into the course the group would become visible/assignable, but the additional users in that group would not show up, or show up disabled/inactive (gray italic or what have you). Groups from the site level would need a different style from groups defined within the course to make them distinctive.

Design 3

Context-wide groups maybe? Possibilities must be a subject of careful consideration. It is clear, that group, defined in some context, may be enrolled in lesser context (either as a whole, or members only, leaving possibility to regroup them. --Oleg Sychev 15:46, 28 January 2009 (CST)

Martin Dougiamas 02:36, 3 February 2009 (CST): I guess cohorts could be defined at category level as well, and appear in the role assign screens below that context. Can't see why it should be for courses too, they might as well just be normal groups.

Oleg Sychev 14:45, 10 February 2009 (CST) : What I'm trying to say there (as above) is does Moodle really need three separate entities (groups, groupings and cohorts)? The more entities will be, the more they are confuse users, and the more work it'll require from the caller (i.e. any module). Should they not be replaced by one carefully thought out entity (presumable group) that can be defined on several levels (remember Occam)? What are the (presumable big) differences of cohort and groupings from groups? It seems that Ray Lawrence and Dakota Duff are working in the same direction.

By the way, worthy (and quite possible) goal is to eliminate most group-handling code from the modules, so any upgrades in group system become much easier. This requires OOP or new global (or new fields in existing global) however.

Design 4

Dakota Duff 11:50, 5 February 2009 (CST) Groups work and are (relatively) easy to understand. No one needs the added complexity of cohorts. They only need groups to be expanded to work on a broader scope and an easy way to determine what groups an individual is a member of.

Groups should have the ability to be defined at a site and category level, in addition to being defined at a course level. Should they also be defined at the module level?
Any group assignment cascades down. If you are a member of a site group you are also a member of that group at the category and course level.
Site groups and category groups have the same features as course groups currently have: a name, an icon, a description, and an enrollment key. There is no need to force themes, languages, etc, as this would require some sort of group hierarchy to determine which theme, language, etc is used for users who are members of more than one group. (More on this issue later.)
Role assignments remain entirely independent from group assignments.
Group assignment is added to searching on role assignment pages and Site Admin user pages.
An option is added to allow site-wide groups to be forced across the entire site (Messages, Front Page modules, etc.)

Let's see how this solves the various problems…

Easy enrollment of large groups of people (site/category group)
Different theme for each group (still thinking about this one ;) — however, groups does not seem the best place, as a user can be in any number of groups)
Only specific courses for specific group of users (site/category group + groupings)
Metacourse synchronization (perhaps not necessary if site/category groups were available?)
Automatic course creation/population (could be handled in another manner — see Martin's thoughts)
Ability to hide some courses from certain sections of users (site/category group + groupings)
Assignment of site-wide activities/resources (site/category group + groupings)

--Bob Singletary 11:49, 6 February 2009 (CST) Question: With this proposed implementation, would it be possible to move the "Available for group members only" option to the Group functionality rather than (or in addition to) the Grouping functionality? For example, the implementation on which I am working only uses Groupings for the singular purpose of hiding activities from some participants but not others. We do not use the Groupings to associate multiple groups. I know that Groupings for that latter purpose is definitely needed, but to have to use it only to hide activities...IMO, having that particular functionality would make more sense at the Group level. Any other thoughts regarding this? Opinions?

Martin Dougiamas 02:27, 10 February 2009 (CST) Dakota, on your first bullet "Any group assignment cascades down." ... would that imply that if you created a group called "Class A" at site level then Class A would appear inside every course on the whole server? So if you go into the groups listing in Course B then you'd see Class A in the list (even though it may not have any people in it?)

Dakota Duff 14:29, 10 February 2009 (CST) Martin, that's how I envisioned it working. It would be nice if in the courses' groups lists all high-level groups had the text in grey or something it would be immediately obvious that you could not change the group settings from that level. Ditto for the group members — grey if they are assigned at a higher level. However, I think it would also make sense that you could still assign users to site-group from the course level (similar to roles). So if you have a site-group, "Group A", and you were assigned to it from the site-level then I could still be assigned to the same group from the course level. In the course's group list, your name would be greyed out because you could not be removed from the group but mine would be in black text because a person with the appropriate rights could remove me from the group.

Martin Dougiamas 02:34, 25 March 2009 (UTC) Hmmm, if one group contains different people depending on the context - couldn't that be quite confusing? I'm also concerned about the performance of this plan (calculating who can do what and who is where) ... we have enormous difficulty keeping Roles under control already ...

Gary Prosser 14:31, 17 July 2009 (UTC) I am finding the descriptions of capabilities, features difficult to follow but it sounds like design 4 fits our needs IF site/category group membership provides teacher access to a group gradebook. Reason: higher ed institutions like ours have pastoral groups which are unrelated to courses. Pastoral group leaders need access to a grade book collection (eg single spreadsheet) for the students in their group.

Dakota Duff 2 22:06, 17 July 2009 (UTC) Martin, I was thinking that the groupings/groups would basically function as-is but with an added field for context. It seems to me this wouldn't hurt performance and it would fit into the existing Moodle mold where roles can be assigned at many levels.

--Dan Ballance 06:54, 20 September 2009 (UTC) Could I ask for some clarification here? I think there is a distinction to be drawn between groups of members that *are available* for enrollment in a course or category and the actual groups that *are enrolled* in a course or category. So when a group is defined at the top system level am I right to assume that it would then be available as a group to enroll in every category and course (but that it still needs enrolling)? Or would defining that group at the system level mean that group is then enrolled in every course? (This would be no use imho with a system that has hundreds of groups in a timetable). With the current local groups, there are no groups available to enroll, there are just individuals from which to build groups. I think a system where when a group is enrolled in a course it just batch enrolls the students into the course and creates a local group of them automatically works quite well. At least having an option for local groups to be mirrors of enrolled site-wide groups would be extremely useful.

Documentation