Obsolete:Groupings and Groups

Improving the Groups design in Moodle

Summary of problems:

• Groupings enabled in 1.8 but not used for anything productive
• Can not define groupings at site level
• Groupings not implemented in modules
• Concept of orphaned groups
• Missing enrolment option
• Not integrated into Moodle core
• Unfinished and partially broken code

Required features

The groupings/groups infrastructure should be finished to allow these features:

• Organize groups into groupings. Groupings are sets of groups related in use or functional logic. Use of groupings should be optional, not mandatory (preserve old-style, pre-1.8, groups usage). A group may belong to several groupings. Real use is easier to setup if this flexibility is allowed.

This is done as by 1.8, but UI imposes the extra requirement of each group to belong to a single grouping.

• Use different sets of groups (groupings) in each individual activity instance in a course. Activities can declare a grouping to use. This means that when that particular activity is set as visible/separate groups, the particular groups used are those belonging to the declared grouping. Hence, we can have simultaneous activities where users are distributed according to different criteria, activities & resources may be targeted to different audiences.
• Group-based access to activities or resources. Only members of groups within GroupingX may see a resource or perform an activity set to use Separate Groups. Users not belonging to any group (in the given grouping) cannot access the activity instance.

This is different to and cannot be managed by Roles & Permissions. Teachers can manage groups but teachers cannot create/delete roles. It would be impossible for large site like a university to manage hundreds or thousands of groups as course-based roles: arbitrary roles from each course would polute the roles-namespace ad infinitum.

• Flexible and easy interface for adding users to groups. Simulation of subgroups: being able to easily select users that are members of a given group and split them into several other groups, while maintaining membership to the first one. Batch creation of multiple groups in a grouping and rules for assigning users to them (each next n users, n random users etc.)
• Display restricted lists of users selected according to membership to specified groupings/groups. In any page presenting lists of users (such as those of Participants list, Assign roles or Group management) there should be possible for the teacher/user to limit the listing to only those users that are members of a given grouping or group, thus allowing the display of only selected users as “potential users” in such lists.
• Define global groups/groupings. Only Admins can create site-wide global groups, organized into groupings for convenience. These global groups may be used for:
  • Controlling dinamically the enrolment of group-members into courses.
  • Restricting the display of users in lists of available or potential users
  • As any other local course-defined group for activities and resources

The list of site-wide global groups may be quite large. Teachers may decide optionally if they use or not global groups at course level; They may "import" or "use" selected groups or groupings inti the course context from the site-wide level.

. Putting groupings to work needs some additional work at module level, and small fixing of groups/groupings libraries --Enrique Castro 19:12, 08 July 2007

---

Examples & use cases

Activities & Resources targeted to different audiences:

We have a course composed of two sections (Grouping Sections: Section01, Section02 each with a teacher) and the same users distributed into Lab groups (Grouping Labs: Lab01. Lab02, Lab03 maybe with assistants as non-editing teachers). You may set the course as “separate groups” using the Sections criterium, and have a separate groups forum for class discussions. Simultaneously you may have a Wiki using Lab grouping to collaboratively construct the laboratory reports within each three Lab groups (so, different and unrelated to Sections groups).

Group-based content delivery:

The teachers want to add special content for lagging students but in way that do not embarrass them, privately, not available for the rest of users. A grouping Special may be defined containing just one group (with students of any section) or several groups of “special” students, one from each section/lab. This may be used to get private content by each teacher in a course. Let say professorA teaches Section1 theory and Lab2 practices. He may set up a grouping called “ProfA” comprising just those two groups (hence, convenience of a group been associated to several groupings).

Defining subgroups:

You participate as a teacher in a three-sections course. You are in charge of Section01. The course is configured to use grouping Sections groups (Section01, Section02, Section03) as separate groups. As part of your teaching you want to separate students into 5-members groups to hold discussions in a forum. You create a grouping “Discussions” as exclusive-membership, containing 6 groups (Diss01-Diss06). While adding students to each DissN group you want that only users of Section01 are listed as potential users and that when added to a group, users disappear of the “potential” listing.

Using global groups:

You are a moodle admin at a university. You define a global group "Foreign Students" and want that all members of that group become enroled into "University primer for foreign students" course, in addition to their regular courses. You are a teacher in a course. Foreign students need special help due to language, you decide to create extra content available only for them: set some resource to separate groups using a custom grouping containing only "Foreign Students" group. You use "News" forum in separate groups mode to send messages to each of you course sections. Those foreigners require special messages, you add "Foreign students" as another group into sections grouping.

Database structure

As of current HEAD (1.9) there are six tables devoted to groups. One each for definitions of groups and groupings , two more for taking care of membership, users into groups and groups into groupings. Two other tables keep the association of courses and groups or groupings. This arrangement is the most flexible as allows both groups existing without being part of a grouping and global groups/and groupings that may be associated to several independent courses. The separation of groups_courses_groups and groups_courses_groupings is imposed by the simultaneous requirements of a) allowing groups to exists and be used without being members of a grouping AND b) the optional use of global groupings/groups locally at course level.

If any of these two requirements is dropped a simpler schema is possible. For instance, if global groups are always available at course level (or no global groups at all) then a courseid field may be introduced into groups and groups_groupings permanently associating a courseid with any group or grouping. Courseid=0 would label global groups. Tables groups_courses_groups and groups_courses_groupings would be no longer needed. Special logic should be introduced into function in groups-libraries to manage this exception (global groups).

On the other hand, if “free” groups are dropped and all groups are required to belong to a grouping another reduced scheme with only four tables has been proposed by Petr Skodak. However, adopting this scheme would implicate to re-write radically groups/groupings libraries.

To make possible to associate a grouping to a module instance a “groupingid” field must be added to the course_modules table. In the same way course table declare a “groupingid” field to hold the default grouping to use in visible/separate group modes. In both cases, there should be no obligation to declare or use a grouping at any level. A default value groupingid=0 must be used in both tables. Groupings/groups managing functions must understand groupingid=0 as meaning to use ALL groups belonging to a course in a flat list (default function in pre-1.8 versions)