Kavi Help CenterKavi® Members Help
| Chapter 13. Roles | ||
|---|---|---|
 |
Part I. Kavi Members Concepts and How-tos | 
|
Table of Contents
Roles are an access control mechanism that Super Administrators can use to exercise fine-grained control over access to the organization's website. Each role grants access to a specified area of the website, and in order to access a protected area, a user must have the right role in their role cache. The most basic example is the default role 'member', which grants the access to Member Areas of the website.
Back to topTo a certain extent, a role could be considered the virtual equivalent of a real-world key. You need to have the right key (role) before you can enter a locked (access-protected) area. This analogy is far from perfect, but it is a simple way to visualize how roles work to control website access.
Conceptualize the organization's website as a brick and mortar facility divided into areas designed for use by different groups within the organization. This facility has a member area, a boardroom, and an administrative office. Each of these areas can be accessed only if you have the right key.
The keys (roles) are labeled:
member - provides access to the Member area
board - provides access to the boardroom
org_admin - provides access to the administrative office and all other areas
Figure 13.1. How Roles Correspond to Areas
A simple website divided into three areas and a set of roles that provide access.
On a website, roles are conferred only through types that are used to classify companies or people according to their relationship to the organization, particularly User Types and Contact Types, as explained in the chapter on Types. To keep things simple, this document refers to types generically.
This may seem counter-intuitive at first. It's easier to understand if you remember that people are not given keys to the organization's facility because of who they are as an individual, but because of their relationship with the organization. The types that confer roles and access reflect positions a user might hold in relation to the organization. This sample organization has 'Regular Member', 'Board Member' and 'Organization Admin' types.
The kind of access needed by each type varies according to the responsibilities of that position, so a type can be associated with multiple roles. The roles that need to be associated with a type also depends on site configuration and which roles provide access to which areas. In our example, the 'boardroom' key only provides access to the boardroom — it doesn't provide access to the members area — so every user designated as a Board Member needs both the 'member' and 'board' keys. On the other hand, the 'org_admin' key provides access to the entire facility, so the administrator only needs one key.
The organization preassembles sets of keys for each type and labels the keys with the name of the type. When a person assumes a new position in the organization and is assigned the type corresponding to that position, they are automatically handed a set of keys (roles) labeled for that type. Every regular member is handed a set of keys labeled 'Regular Member' and every board member is handed a set of keys labeled 'Board Member'.
Table 13.1. Types, Roles and Access Areas
| Type name | Associated roles | Areas to which these roles grant access |
|---|---|---|
| Regular Member | member | Members Area |
| Board Member | member, board | Members Area, Boardroom |
| Organization Admin | org_admin | Members Area, Boardroom, Administrative Offices |
If an organization offers regular and board memberships to individuals, it might create 'Regular Member' and 'Board Member' User Types to be assigned to individuals through membership. Both of these would be associated with the 'member' role, so a user could acquire the 'member' role by being assigned either of the 'Regular Member' or 'Board Member' User Types.
If an organization offers memberships to companies, the scenario is slightly different. If the organization offers regular and board memberships to companies and creates 'Regular Member' or 'Board Member' Company Types associated with the 'member' role to be assigned through membership. When a company acquires either type of membership the company is automatically assigned the corresponding Company Type. Users who sign up as representatives of this member company now inherit the 'member' role through their company. This is the way that most users acquire basic website access privileges in organizations that offer company memberships.
When a custom area is added to a website, a custom role is often created just to provide access to this area. This may be an area created specifically for certain types of members, such as in our previous 'Board Member' example, or an area reserved for other kinds of users, such as legal staff. If an area is created for use by legal staff, a 'legal' role might be added to grants access to that area. The 'Legal Staff' type would be associated with the 'legal' role and assigned to members of the legal staff to provide them with the access they need.
Administrators and editors require a higher level of access than other users. These privileged users acquire the permissions they need by being assigned types designed specifically for their position. Many of these types are built into the system, including the default 'Primary Contact' type, which confers the 'company_admin' role that grants access to Company tools used to maintain company information. Some privileged types, including 'Primary Contact', are usually assigned automatically, but most are assigned manually by administrators. One individual may fulfill multiple functions in the organization and be assigned multiple types. This individual would acquire every role conferred through each of these postions.
The set of all roles accumulated by a specific user is referred to as the user's "role cache." Following our earlier analogy, you might envision the role cache as one or more sets of keys—each set corresponding to a type assigned to the user or their company.
In actuality, a user's role cache is simply a list of all the roles the user has been granted through all the types assigned to the user. Since a user may be assigned any number of types, and acquires every role associated with each of these types, a user may have multiple instances of the same role in their role cache. Administrators can view a user's role cache through the Manage a User tool to determine what roles and website access privileges the user holds.
Figure 13.3. How Types Affect a User's Role Cache
An example of how types affect a user's role cache and access privileges.
This example shows the role cache of a user who acts as primary contact for a company with a Board membership. The company was assigned the 'Board Member' type when they acquired their board membership. When this user signed up as a company representative, they inherited the 'board' and 'member' roles through their company. Because this user signed up as primary contact, they were also automatically assigned the 'Primary Contact' type, which confers the 'company_admin' role.
Whenever an authenticated user enters a URL or clicks a link in their browser, the browser sends a request for the page and its contents to the webserver. The webserver checks to see which roles the webpage requires, then checks the user's role cache to see whether the cache contains any of the required roles. If the required roles are present, the webserver sends the webpage and whatever contents the user is authorized to see.
Elements within a page might require different roles, so a user who lacks some of these roles might be able to view the page but not see all of its contents. For example, a page displayed to a user with administrative roles (e.g., 'company_admin' or 'admin') may include links to Admin Area tools that don't appear when this page is displayed to a member or staff person who doesn't have these roles in their role cache. For a graphical illustration of how roles can influence the way pages are displayed, see the section on Page-level access control in the Access concepts document.
Kavi Members installs a set of default roles that grant access to standard webpages and tool menus. It isn't the only source of roles managed through the Kavi Members Manage Roles tool. Other applications automatically add default roles when installed, and custom roles may be added by Super Admins to provide access to custom tools and webpages. For more information, see Kavi Members Default Roles
Since roles can only be conferred through types, each default role is associated with one or more default types, as described in Types and Kavi Members Default Types. Note that default types are editable. If the types on your site have been edited, they may not be associated with the roles listed here. You can verify the configuration of default types for your site by looking up the type through tools available in the 'Types and Roles' section of the Super Admin menu.
Back to top|
|
 |
|
| Chapter 12. Status, Activation and Deletion |  |
Chapter 14. Types: Company, User and Contact Types |