Obsolete:Site-wide groups

Requirements

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

1. 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?)
2. 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.
3. 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?
4. Being able to create and populate classes automatically, either from LDAP OUs or via web services Matt Gibson 05:08, 22 January 2009 (CST)
5. Support for site / category wide groupings. This could remove the confusion and other issues associated with some of the site configuration options where users wee too much. This could enable complete separation where required for year groups, clients etc.

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.

Possible plans for discussion

Design 1

1. Let's call them cohorts and keep this separate from existing groups system.
2. Admin can use an admin interface to define cohorts (with name, icon, description, forced theme, language etc)
3. 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)
4. 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.
5. The cohort theme beats site theme, but is beaten by user or course themes.

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

Design 1 LDAP

Tying this design into LDAP too would be great!

1. Cohorts are defined in admin section then associated with LDAP OUs and / or security groups.
2. Using LDAP sync script, if a user is moved or added to a new group they are automatically added to the cohort in Moodle
3. Users then receive the associated courses / roles that their cohort is assigned to.

--Jon Witts 17:46, 22 January 2009 (CST)

Design 2

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. --John E 10:22, 28 January 2009 (CST)

1. Groups are defined on site level.
2. Groups qualify as assignable entities on role assignment screens (on any context).
3. 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.)
4. 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?).

See also

The main tracker bug is MDL-11826