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. Groupings are not used for any of the logical purposes (see below)

• 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.). A way for users to self-enrol into groups of teacher-selected groupings should be added.
• 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

• allowing groups to exist and be used without being members of a grouping (i.e. traditional way pre-1.8)

AND

• the optional use of global groupings/groups locally at course level.

If any of these two requirements is dropped a simpler schema is possible.

This database scheme allows to search for course groups or user groups in a single query, as in pre-1.8 moodle. Any required group-data may be obtained by either a join of usually just two tables, or two separate queries, one for grouping and other for groups in grouping.

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)

Changes into current tables

Now the table groups_groupings include a series of fields intended for controlling access permissions to a group (student/teacher view, grading etc.) These should be eliminated and managed through the regular permissions infrastructure.

Conversely, some other fields should be added to allow more convenient use of groups by teachers.

• editable - to allow users to edit or now their own group
• exclusive - to allow multiple-group membership within a grouping or impose single-group membership: a user can be member of just one an d only one group of this grouping.
• publish - teacher decides when a grouping is enabled to be used in the course (important if group self-selection is to be managed)
• sizelimit - number of places for groups in this grouping (important if group self-selection is to be managed)

Putting these as grouping attributes rather than individual groups makes coding easier because then all groups in a grouping are expected to behave in the same way and can be treated alike.

Alternative, Reduced schemes

If the above requirements are not be met simultaneously, simpler schemes for the database tables are 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 functions 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.

Backward compatibility with pre-1.8 groups

Before version 1.8 all groups within a course were managed in a single flat list, without groupings. Multiple-group membership was introduced in version 1.6. To maintain compatibility we must not insist on having each group to belong to a grouping. Groupings should be viewed as an optional feature used only if needed. When the teaching requires them, not imposed. The main actors in the groups/grouping dichotomy should be groups, not groupings: the teacher should create groups at first, and only if needed those groups could be placed into gropings.

Actually, making mandatory to put each group in a grouping creates some problems:

• A "default grouping" must be created whenever groups are to be used
  • Teachers using only a flat list of groups as course sections with separate groups mode must not be compelled to create a "default grouping" just to hold them.
  • This requirement is also a problem when restoring groups from old versions: an exception must be added to create a grouping non-existent in the backup zip.
• Deleting a grouping will create "orphan groups" that needs exceptional pseudo-grouping to manage them.

If groups are main actors, not groupings, the concept or necessity of "orphan groups" pseudo-grouping can ve avoided at all.

When groupings are created and populated with groups the API functions must return/operate on a flat list of ALL course-associated groups if no groupingid is specified or groupingid=0. Legacy group functions must be modified to operate by default on groups of the “currentgrouping” or all groups if no groupingid is specified or groupingid=0.

Activities declare a grouping to use groups

The configuration form for each activity includes a setting for groupmode: “no groups”, “visible groups” or “separate groups”. If the activity (or resource) is configured in any of the later two (visible/separate) then a new option “Use grouping” must be set. This parameter controls the particular set of groups to be used within the activity.

Module instances keep the groupingid parameter in course_modules table. This parameter should be added to "common module settings" to be managed by all modules in the same way as groupmode and visibility settings.

All calls to groups/groupings-managing functions within a module code must ensure to pass the groupingid parameter (0 o null meaning no groupings i.e.: all groups).

Group-based content delivery

If a module instance is set to use separate groups then ONLY those users that are members of a group included in the grouping used by that particular module instance may access to the module content (either resource or activity): “non-grouped” users are excluded. This should be implemented both for Activity modules and Resource module. Visibility and accessibility of module instances should be checked before printing in UI. Activities and resources at which the user access is forbidden must not be showed to the user.

Global Groups

Separate global and course groupings, add global tag to group/grouping table. Each global group/grouping has world wide unique identifier. Benefits:

• allows implementation of access control – local course groupings editable by course teachers, special capability in CONTEXT_SYSTEM for managing of global groupings
• easier backup/restore implementation – local groupings (+groups) always backed up, global groupings handled differently

This separation would make the coding much easier because the two parts would be independent - local grouping would not be breaking the course separation rule (anything outside of course breaks normal backup/restore).

Local groups/groupings would be attached to exactly one course, global groups/grouping could be used in many courses at the same time. These limitations are not built into the database schema but imposed by UI: all groups created within a course are automaticcaly associated with that course, only global groups displayed import/emport

Define global groups/groupings.

Only Admins and users with moodle/site:manageglobalgroups can create site-wide global groups and groupings. A UI must be provided in Site Administration to manage those groups.

Group-based enrolment

Global groupings can partially replace metacourses in some scenarios. They should support synchronization of enrolments based on group membership. Global groupings should allow:

• automatic or manual sync of enrolments – reuse code from metacourses
• setting of default sync role id with possible exception for teachers, tutors, etc.
• import/export of grouping definitions
• mapping of global groupings during course restore (course groupings always backed/restored)

Use selected global groups in local course-based activities

Global groups should not be available as default within a course group UI. That only contributes to polute namespace and confuse teachers. Courses may “import” selected global groups to use in local course-based activities. A UI must be provided for importing either whole groupings (with their groups) or individual global groups to course context. Imported groups and groupings must be locked (no users or groups added/removed at course level). Imported groups may be added to local groupings just as any regular, local, group. Then those activities are open for users that happen to be enroled in the course and are members of a site-defined group: a two way checking. Functions in groups/groupings API must enforce this double checking by reading the "global" flag.

Groups/grouping management UI at course level

The user interface must emphasize the Groups management and add Groupings as an option in a separate, secondary, tab. Additional tabs may be added for extra functions like batch creation of groups and import of global groups/groupings

The classic three pane page has proven very convenient and powerful to manage groups. There is no reason to change it.