The permission layers explained (Group 1.x)

Note: This page only applies to permission for Groups 1.x; Groups 2.x uses an entirely revamped system.

When using Group RC1 or higher, you have several options to assign permissions to a user within or outside of a group. I'll go ahead and explain the way it all works first and then show how some common access scenarios can be tackled using Group.

Anonymous users

These are users that have no account on the website and therefore share the same set of permissions at all times. They can be assigned permissions in the global scope at /admin/people/permissions and permissions per group type at /admin/group/types/manage/{group_type}/permissions.

Because there is no way to identify them individually, they cannot join any group as we would not know who to create a membership for. You'll notice this when trying to set group permissions that any permission which would not make sense to have as an anonymous user cannot be selected. E.g.: Edit own membership, leave group, ...

Authenticated users

This is the catch-all term for users that do have an account. In the global scope they all receive permissions from the "Authenticated user" role, but can receive even more permissions from custom roles that are assigned to them.

In the group scope, we have a similar system for both people who are not part of a group and those who are.

When not a member of a group

Authenticated users who are not part of a group are regarded as outsiders to that group. Just like the "Authenticated user" role in the global scope, we have a catch-all role for them in the group scope: "Outsider". You assign permissions to this group role at /admin/group/types/manage/{group_type}/permissions and anyone with a site account that is not part of a group will receive the Outsider permissions for that group.

However, we realize there might sometimes be a need to distinguish between outsiders based on what roles they have in the global scope. This is possible by visiting the "Advanced outsider permissions" page at /admin/group/types/manage/{group_type}/permissions/outsider. On that page, you will see roles with the same name as those in the global scope found at /admin/people/permissions.

Setting permissions on any of these roles will ensure that anyone having the corresponding role in the global scope will also receive the permissions you set in the group scope, as long as they remain an outsider to the group; i.e.: are not a member.

When a member of a group

Authenticated users who are part of a group do not receive the Outsider permissions, but Member permissions instead. You can configure extra group roles per group type in a similar fashion to creating extra roles in the global scope. These group roles behave the same way that global roles do in a sense that they can be additional to your automatic Member role as long as they are assigned to your membership.

Simple flowchart

Below you'll find a simple flowchart to use when trying to figure out where to set someone's permissions.

Common use cases

I want people to be able to create groups.

Create the group type first and then in the global scope, i.e.: at /admin/people/permissions, allow them to create groups of that type. The reason this needs to be assigned in the global scope is that if a group does not exist yet, we obviously can't read out any group permissions for it.

I want people to be able to join groups and post content in them.

Assign the Outsider role the permission to join the group and the Member role the permission to post content. Once someone has joined a group, they will be able to start posting content in it.

I want a private group that only allows admins to add people.

Create a group role, e.g.: "Group admin", and assign the permission "Administer group members" to it. Set up the group type so that the creator of the group gets a membership with this role. Anyone who creates a group can now add members to the group without people being able to join the group the regular way (i.e.: "Join group" button).

I want my site admins to be able to administer all groups without having to join them.

Assign them a global role, e.g.: "Site admin", and then assign the "Administer group" permission to the matching advanced outsider role in the group type configuration section. Anyone with the "Site admin" role set to their account will be able to administer all groups they are not a member of.