Groups access control

Jump to: navigation, search

Group modes

There are three group modes:

  • no groups (NOGROUPS) - groups should not be used in course or activity
  • visible groups (VISIBLEGROUPS) - users or also teachers are divided into groups, all users have access to all groups
  • separate groups (SEPARATEGROUPS) - students or/and teachers are separated into groups, access to non-member group is usually prevented

These group modes do not have any strictly defined meaning, activities have to define the exact meaning and have to enforce the access control manually. There is no automatic implementation of group mode in core infrastructure.

The SEPARATEGROUPS mode means that users and non-editing teachers should not be able to find out the names of users in other groups, unfortunately the group mode support may be completely missing in some activities or there might be bugs that result in information leaks across groups. It is strongly recommended to use separate course if maximum privacy is required.

Groups at course level

Groups at course level are defined relatively vaguely, each area may use different logic.
is used to obtain/change current group. Developers have to pay extra attention to 0 returned from groups_get_course_group() in SEPARATEGROUPS mode. Pages/code that does not use current user group from groups_get_course_group() (i.e.. accept group parameter from url) must verify the group parameter is valid (i.e.. in SEPARATEGROUPS mode user is member of that group or has access to all groups).

Groups should not be used to mark users with special needs or disabilities because the group membership is not treated as private information and may be accidentally displayed to other users in course or even guests.


In VISIBLEGROUPS mode all groups from default course grouping may be used for filtering, teacher group membership is used for selection of initial filtering only.

In SEPARATEGROUPS mode teachers with moodle/site:accessallgroups capability can access grades of all users, teachers without this capability may access only users from their group. Teachers without any group membership and access to all groups can not view or display grades of any other user.

Teacher here is user with moodle/grade:viewall capability. Please note some reports such as overview or user may use slightly different access control.

List of participants

The VISIBLE groups mode can be show users membership to one or more groups. Everybody may see what is member of other groups.

In SEPARATE mode users see only members of their own groups, users with access moodle/site:accessallgroups may see members of all groups.

Course user profile

The logic is similar to the list of participants.


Enrolments overview UI ignores group restrictions because it is used to enrol users into course and assign them to groups.

Groups at activity level

Group support can be implemented only in activities where users actively participate, technically there is nothing to group/separate if there is read only access such as in resources (i.e. no posts, no ratings, no comments)


Each forum discussion has a group flag. 0 means all users may see a discussion, in separate mode only users with access all groups may post in a discussion with group 0. Non-standard -1 means that groups are not used. Number indicates a group id.

In SEPARATEGROUPS mode users may view discussions for member groups or 0, ordinary users may post only in member groups only, access all groups capability is required to post in discussions for all groups (discussion group == 0). In separate groups mode the forum prints a warning if the user is not a member of any group and does not have access to all groups.

In VISIBLEGROUPS mode users may see posts in all groups but may only post in the member groups unless they have access all groups capability.

The forum prints group membership icons next to each user post no matter what group mode is selected, the only way to prevent this group membership disclosure is to select grouping without groups in the forum settings page. User lose access to their own discussions if they are removed from separate group, all users may still see their posts in original group because the discussion group flag is used for access control.

Forum code may not work well if you delete already used groups or change grouping.


Database activity is similar to forum implementation, it may be a bit less complex though.


There should not be any subwiki for all groups, in group modes each group should have a group specific version of each wiki page. In visible mode users should be allowed to read all groups and modify only member group subwikis. In separate mode users should be allowed to read and modify only member subwikis. Access all group capability allows user to view and modify all group subwikis.

NOTE: wiki in 2.0.2+ is known to have incorrect groups implementation.


The group mode handling is similar to gradebook, the difference is that current gradebook reports work with capabilities in course context only, the assignment module verifies capabilities in module context.

Group membership and restrictions is calculated on the fly, there is no group flag in submissions.

In separate mode all teachers may grade/view submissions of any user. In separate mode teachers may grade/view own group only, access all groups allows them to view/grade everybody.


TODO: add more information

Common problems

  1. group mode is not implemented at all in some activities (glossary)
  2. developers forget to verify group access completely in SEPARATEGROUPS mode - ajax scripts, action scripts, graphs, file access, etc.
  3. developers forget to handle case when current group is 0 in SEPARATEGROUPS mode
  4. users believe that forced separate groups can not leak any information
  5. tags may not be group aware
  6. notes may not be group aware
  7. experimental groupmembersonly feature is not related to groupings at all! (not used anymore, since Moodle 2.9)