Obsolete:How groups work in Moodle

Jump to: navigation, search

Note: You are currently viewing documentation for Moodle 1.9. Up-to-date documentation for the latest stable version is available here: How groups work in Moodle.

IMPORTANT: This page is now obsolete! see Development:Groups instead.

IMPORTANT: This documentation does not refer to current (1.6/1.7) versions of Moodle and is here at the moment purely in order to obtain comments. Descriptions of how groups work refer to how they hopefully work not how they will work now! This document is also written in the present tense even though it doesn't refer to the current version of Moodle. This is so I don't have to go through and change it all in a month or two's time.

How groups work in Moodle

It is possible to have groups of users in Moodle. A person with the right permissions (generally an editting teacher or admin) can create groups for a course and add and remove users from groups. They can also create sets of groups for the course which we'll refer to as 'groupings'. Groups that belong to the course can be added to and removed from any of the groupings that have been created for the course.

If you haven't seen the interface for creating groupings and groups, I'd recommend you go to a course in your installation of Moodle for which you have edit access and which has some participants and follow the Groups link and take a look (note: you can't currently do this obviously as the code isn't released yet!).

An example

  • Your course has five students: Alice, Bob, Charlie, David and Eve.
  • You create two groupings - 'Grouping 1' and 'Grouping 2'. You create three groups for Grouping 1 called Group X, Group Y and Group Z and you create two groups in Grouping 2 called 'English student' and 'Scottish students'.
  • You put Alice and Bob in Group X, Charlie and David in Group Y and Eve in Group Z.
  • You put Alice and Charlie in 'English students' and Bob and Eve in 'Scottish students' (David is Welsh so we don't put him into a group at all).


  • You now create a wiki and a forum. You assign Grouping 1 to the wiki and Grouping 2 to the forum.
  • The wiki now uses the groups Group X, Group Y and Group Z. The forum now uses the 'English student' and 'Scottish students' groups. As David isn't in any of the groups for Grouping 2, he doesn't even see that the forum exists.

More details

Once there is at least one grouping created for a course, when an editor adds an activity (i.e. an instance of a module) to a course they may if they wish assign one of the groupings for the course to use with that instance of the module. A user who is not in a group for a grouping assigned will not be able to see that the instance of the module exists. It is also possible for the editor to specify a grouping to use for everything for the course - this is set up in the course settings.

Each group and grouping must 'belong' to at least one course (it's possible for them to belong to more than one course, but there's no user interface to let you do this easily at the moment). Both teachers and students can belong to groups and a user can belong to more than one group. It is also possible for a group to belong to more than one grouping and for a user to belong to more than one group in a grouping.

There is a choice of various permission settings for a grouping - for instance you can specify that students may both view and contribute to the group of which they are a member but only view groups of which they are not members. In time these settings wil hopefully be superceded by an extension of the roles and permission system used elsewhere in Moodle, but at the moment they are independent. The main types of permission that a user can have for a particular group are 'student view', 'student contribute', 'teacher view' and 'teacher contribute', with it being up to modules to decide how to interpret these. As we have seen, a user does not need to be a member of a group to have a particular permission type for that group.

How does this differ from the way groups previously worked?

  • Previously it was only possible to have one set of groups for a course. All activities for a course had to use the same set of groups, whereas now you can use different sets of groups for different activities.
  • Previously, for a course with groups, there were two groups modes - separate and visible. With separate groups, students

could not see groups to which they did not belong, whereas with visible groups they could see groups to which they did not belong but not contribute to them. This caused a great deal of confusion when it came to teachers belonging to groups (and also led to lots of really horrible logic in the code).

  • You can now create groups automatically with a certain number of students per group randomly assigned, or with students distributed into a certain number of groups.
  • If a student is not in a group for the grouping assigned for an activity, they will not be able to see that activity.
  • The infrastructure supporting groups has been improved considerably so that it will make it much easier to make changes to groups in future as well as to module code. For instance, the changes to support global groups should now be fairly simple. If somebody wants to integrate groups with the roles and permissions system in some way this should also be much easier than it previously would have been.

Future plans? (Things I'd like to do or you can do for me!)

In no particular order:

  • Bug fixing I guess :-)
  • Global groups - I want it to be possible to set up groupings for course 1 and for these to be visible for all courses on the site, but not editable or deletable. I think this code should actually be quite easy to write now and I might even do it before this code is put in, just haven't done it yet.
  • A nicer user interface (that doesn't break the back button :-) Ajax separates the back and front end of the code really well, so if anyone has good ideas on this, it should be quite easy for someone else to do without having to know how the internals of the groups code work.
  • Integration with roles and permissions
  • Sign up sheets for groups
  • Proper support for blocks and global features.
  • A way for modules and blocks to declare whether they support groups or not.
  • Putting in search_users functionality for group permissions as well as just members of groups.
  • Cool ways to set up groups automatically for particular pedagogical reasons - things like minimising overlap with groups in another grouping, creating groups just from the users all in another group and creating groups which merge pairs of groups from another grouping.
  • Allow settings for groupings which restrict users from being in more than one group, number of people per group, etc.