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)

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)

See also

The main tracker bug is MDL-11826