Apply roles to your members with this community package

Some businesses have more complicated requirements for their authenticated members than the example in the earlier membership guides covers.

For example, a business may need to have multiple groups of members, each of which has access to different pages. You could achieve this behavior if it were possible to assign roles to members, using those roles to restrict access to certain pages.

The package

Kentico plans to include roles for members in Xperience, though it it does not yet have a firm position in our roadmap at the time of writing this guide.

In the meantime, Kentico MVP Trevor Fayas has created an open-source community module for assigning roles to members and controlling which pages they can access.

Visit the XperienceCommunity.MemberRoles repository to view the module and find instructions for how to install and use this package.

This guide will give a brief overview of this member roles package and highlight some of its noteworthy features.

How it works

Let’s take a high-level look at the components of the member roles package.

How do the objects relate?

Instead of creating a new object type, Trevor’s repository uses taxonomy tags to represent the roles members can have.

There are three binding classes used to create relationships between these roles and the following objects:

1. Members in the Members application.
   • A binding object relating a role to a member means the member is assigned to the given role.
2. Web page items in web channels.
   • A binding object relating a role to a web page item means that with correct configuration, members of the given role have permission to view the page.
3. Content folders in Content hub.
   • A binding object relating a role to a content folder means that with correct configuration, members of the given role have permission to view reusable items in the folder.

Then, there are two Permission settings classes: one for content folders and one for web page items. Each object of these types is associated with a single page or folder and specifies two things:

1. Whether the given page or content folder should restrict unauthenticated members.
2. Whether the list of permitted roles should be inherited from the parent or directly defined for the given object.

Finally, XperienceCommunity.MemberRoles includes a Member Permission Configuration reusable field schema, which indicates whether the package should check role permissions for a given content type. We’ll cover this vital schema in more detail under the next heading.

How do you configure an item’s permissions?

You may have noticed the phrase “with correct configuration” qualifying a few statements under the previous heading. Let’s dive into that a bit further.

There are two important factors that designate if and how the member role code should check an item’s permissions:

Reusable field schema (the “If”)

As mentioned above, an item’s content type must have the Member Permission Configuration schema if you want to evaluate its permissions. You need to apply the schema both in the database (by assigning it through the admin UI) and in the code (by re-generating code files for the content type).

Inheritance (the “How”)

The way the package checks an item’s permissions is determined by setting permission inheritance.

If a web page item is set to inherit permissions, permission checks for that item will check the permissions settings of the parent item. If it’s set to Break Inheritance, the package will check the permissions assigned directly to the item in the Member Permissions category of its Properties tab.

If a content folder is set to inherit permissions, permission checks for the reusable items it contains will evaluate the settings of the parent folder. If it’s set to Break Inheritance, the package will check the permissions assigned directly to the folder in the Folder Permissions application.

How do you check permissions?

The Member roles module provides new code that can filter unauthorized content from the current member. It’s important to note that Xperience does not automatically apply this new logic, so you need to adjust your code wherever you retrieve content that may be restricted by member role.

This process will be easier if you use some form of abstraction that centralizes your data access logic.

Can you tie it in with authorization?

The Member roles package includes logic to filter queries for content items based on member roles, but you can expand its utility further using another of Trevor’s tools.

The XperienceCommunity.DevTools.Authorization.MemberRoles package allows you to authorize things like controller actions and page templates based on member roles.

You can find specific instructions about its installation and usage in the link.

How to help your business users

Many educational textbooks surrounding technology teach that information systems are made of five components: hardware, software, data, procedures, and people. Since the member roles module is a community-developed system that is not directly integrated into Xperience, it needs to rely a little more on procedures and people.

Get started

Find instructions for installing and using the package in the repository to include member roles in your project today.

The project is open-source, so you are free to fork and customize it to fit any of your specific needs.

If you encounter any problems, please report them through the Issues tab of the repository.

If you have any ideas for functionality you’d like to see training guides about, please let us know with the Send us feedback button below!