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.

Obsolete:How groups work in Moodle

From MoodleDocs
Revision as of 07:59, 22 August 2006 by Helen Foster (talk | contribs) (categories)

IMPORTANT: This documentation does not refer to current 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!).

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.

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.

As well as modules, there are also some blocks and global features such as blogs and the calendar that use groups in certain ways. We'll come to those later.

It is obviously good if modules support groups in the ways that users expect! This document is here to try and help you do that - if anything isn't clear, you have questions or can think of improvements to how groups work in Moodle, please post on the Groups forum on moodle.org.

How does this differ from the way groups previously worked?

The biggest difference is that 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. This is the main reason that the API needed to change.

Also, 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 module code trying to work out who could view or contribute to an activity. This is why the separate/visible groups modes have been replaced by a clearer and more granular permissions system.

Another big difference that isn't obviously visible is there are now tables in the database for course_groups and courses_groupings, whereas previous the groups table had a courseid column. This made it very difficult to use the same group for more than one course. This should now be much easier. However this obviously affects any code that used to access the groups table directly.

There are also improvements to the user interface for creating groups, though these aren't specifically relevant to module developers.