Warning: This section describes obsolete functionality!
Starting from Groups 2.x and Groups Restrict Categories 2.x, access control is based directly on groups. The following sections describe how to control access based on groups and alternatively based on capabilities as used previously in Groups 1.x and Groups Restrict Categories 1.x. We recommend to use access control based on groups – alternatively, capabilities are supported when legacy access control is enabled in Groups 2.x with Groups Restrict Categories 2.x or when you are using Groups 1.x with Groups Restrict Categories 1.x.
Access Control based on Capabilities
The following applies to Groups Restrict Categories 1.x or Groups Restrict Categories 2.x and Legacy Access Control enabled in Groups 2.x. For systems running Groups 2.x and Groups Restrict Categories 2.x, we recommend to use access control based on groups instead.
Let’s walk through a simple example with a new category. This would be a good example if you have just installed Groups and Groups Restrict Categories. Here we will create a new category, a new group and a new capability in one single step.
Go to Posts > Categories and under Add New Category, input “Premium” (without the quotes) in the Name field. Move down and under “Enforce read Access” you will find two fields. We will use the second field for this example*. The second field is usually showing a placeholder text that says “Quick-create group & capability”. Input “Premium” in that field and then click the “Add New Category” button.
You will find your new category in the list of categories showing premium in the Access Restrictions column.
Assuming that you have just installed Groups and Groups Restrict Categories, you have just created three entities: a new “Premium” category, a new “Premium” group and a new “premium” capability. Only users who belong to the Premium group will be able to access this category and the posts that are in it. If one of those already existed, they would have been re-used and related appropriately.
Note that although in this example the category is named Premium and we have used the quick-create feature to create a group of the same name, we could have used Bunnies in the quick-create field instead. It doesn’t make a difference, although in this case it’s just easier to follow conceptually.
* The first field lets you choose a capability, the second one lets you input a name. If you do not see the second field, or none at all, that means that you do not have sufficient privileges and you will need to ask an administrator to grant access or define the necessary entities for you.
Note that when a taxonomy is restricted ( e.g. a Category) and is also added in the navigation menu, it will appear for all users, but only authorized users can visit and see its contents.
If you already have defined a capability and enabled it for access restriction, then you can choose it in the Enforce read access field. Note that only members of a group that has the capability assigned will be able to access the category.
Restricting an existing Category
Go to Posts > Categories and click Edit for the desired category (if you don’t see the Edit link, move the cursor over the category’s name).
Under “Enforce read access” you will find two fields, the first field allows to choose from existing capabilities that are enabled for access restriction. The second field allows to define a new group and capability on the fly, this second field is only available for Groups administrators, if you do not see this field, you will only be able to apply access restrictions which have already been granted to you by an administrator using the first field. If you are not being offered any access capabilities to restrict a category, you will have to ask an administrator to enable one for you.