Note: You are currently viewing documentation for Moodle 1.9. Up-to-date documentation for the latest stable version is available here: Site-wide groups.
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)
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)
Possible plans for discussion
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.
- A checkbox would allow you to choose whether cohort changes are mirrored as changed enrolments in future (hooked in role_assign and role_unassign)
- 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
--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.
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.
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 ...
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.
Dakota Duff 11:50, 5 February 2009 (CST)
The main tracker bug is MDL-11826