Obsolete:Site-wide groups: Difference between revisions

Revision as of 20:00, 21 January 2009

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 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?

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

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 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.
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?

@@ Line 5: / Line 5: @@
 # 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.
-# What else?
+# 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?
 == Terms ==