Kavi Help CenterKavi® Members Help
| Chapter 18. How to Manage Access | ||
|---|---|---|
 |
Part I. Kavi Members Concepts and How-tos | 
|
Table of Contents
User access to Kavi Workspace is managed primarily through the Kavi Members application. Access settings are configured by Super Admins, who define the processes by which individuals and companies are added to the database, the types and roles that will be assigned to grant website access, whether these types are assigned automatically or manually, and the conditions under which types and access are automatically revoked. Organization Admins are given enormous control over access management, so administrators need to understand the material presented in the Concepts documents Roles, Types and Access before you can understand how these are implemented on your organization's website.
Back to topHere are some tips to help you get a high-level overview of the ways that access is granted to your website.
Go to the Admin menu and click the link to the View Access Configuration page. This shows all the types and roles that exist on your website. If Kavi Membership is installed, you'll see which types are assigned through each membership type.
Organization Admins can click here to go to the View Access Configuration page. You may want to save a copy of this page or print it out for reference.
Roles are like keys that confer access to role-protected areas of the website. Your organization may have many roles, but most are easily categorized. These are all listed on the View Access Configuration page.
If you are a Super Admin, you can use the Manage Roles tool to determine whether a role is installed by default or specific to your website. Look in the 'Origin' column. A default role displays the name of the Kavi application that installed it. If the word 'custom' is displayed, this role was added specifically for your website. Super Admins can click here to go to the Manage Roles tool. For more information, see Roles in the Concepts section.
Default roles are documented in the Appendix document Kavi Members Default Roles. If the role was installed by a different application, click the link to go to the list of roles and types for the other application. Default roles commonly provide access to large areas of the site, as shown in Schema of main access areas.
With the exception of roles created automatically for Editor User Types, created in Kavi Edit to give access to a specific set of editable pages, additional roles are not used in Kavi Workspace Standard installations. Kavi Workspace Enterprise installations may have additional roles created specifically for built-to-suit tools or areas. The role name and description should tell you the corresponding area of the site.
Since users inherit roles from Company Types assigned to their company, Company Types tend to grant basic access to Kavi Members User Tools. Additional access can be granted by layering on User Types or Contact Types.
Administrators can click here to see the View Access Configuration page. Super Admins can use Manage Company Types to view these types and see which ones confer roles. Click here to go to the Manage Company Types tool. For more information, read Company Types in the Concepts section.
You may have one or two default Company Types in use on your website. The 'Members Area Access' type confers the 'member' role to provide access to Member Areas and User Tools. The 'Groups Area Access' Company Type confers the 'wg_access' role and access to the Kavi Groups All Groups page. Some organizations use the 'member' role to gate Kavi Groups access, in which case the 'wg_access' may be absent or the 'Groups Area Access' type may not be assigned to any companies.
For additional Company Types, look in the 'Roles' column to see if the type confers roles, because these are the only types that grant access. See if you can tell how privileged Company Types are assigned. They may be assigned automatically based on purpose, or if Kavi Membership is enbled, assigned through membership, in which case their 'Category' is 'general (with membership only)'.
The next most common custom Company Type with roles are types assigned to staff companies. Types created for Web design companies are sometimes associated with highly privileged roles such as 'Editor'. More commonly they are associated with default roles that provide more limited privileges or custom roles that provide access to areas created specifically for their use, such as 'legal'.
Custom Company Types with roles may be created to group people who work directly for the organization. This kind of type is much more likely to convey highly privileged roles than other types.
Use the Manage Contact Types tool to look up these types and see which ones confer roles. Roles conferred through these types usually grant access only within a company-specific scope to give company representatives the access they need to manage company data and content.
Administrators can click here to see the View Access Configuration page. Super Admins can use Manage Contact Types to view these types and see which ones confer roles. Click here to go to the Manage Contact Types tool. For more information, read Contact Types in the Concepts section.
Identify the default types and look them up if you aren't sure what they do, since some of them (particularly Primary Contact) are deeply integrated into the Kavi Members access control system, and all of them represent important players with specialized responsibilities and access. Default Company Administration and Contact Types can also be installed by other applications. Most of these have the term 'Company' in their name (e.g., 'Showcase Company Admin'). For more information, see Kavi Members Default Types. Remember that these types can be edited, so you need to look up each type to see which roles are granted through these types on your Web site.
Now find custom Contact Types with roles and study the name, description and associated roles to determine what access privileges are granted and what kinds of users need to be assigned this type.
There are several default User Types with high-level privileges that are usually assigned only to organization administrators. If the organization gives accounts to individuals (and not just companies), the 'Members Area Access' and 'Groups Area Access' default User Types may be installed. Like their default Company Type counterparts, these confer the 'member' and 'wg_access' roles respectively, and provide access to Member Area User Tools and the Kavi Groups All Groups page. Some organizations use the 'member' role to gate Kavi Groups access, in which case the 'wg_access' may be absent or the 'Groups Area Access' type may not be assigned to any users.
If Kavi Membership is installed and your organization offers memberships to individuals, additional User Types are installed. There are custom types assigned through individual memberships, privileged default types that convey administrative and editor roles and other custom types created for types of users that are unique to this site. These may grant lower levels of administrative and editorial access or roles needed to access custom tools or areas of the site used specifically by this kind of user.
For more information, see Contact Types in the Concepts section. Super Admins can use Manage User Types to view these types and see which ones confer roles. Click here to go to the Manage User Types tool.
Identify the default types and look them up if you aren't sure what they do. Most of these are highly privileged types that convey roles that grant access to Kavi Edit or administrative tools. Since they represent the most privileged users in the system, it's important to be familiar with them. You can look them up in Kavi Members Default Types.
Now find other custom User Types that have roles, and study the names and descriptions of the associated roles to determine what access privileges are granted and what kinds of users are assigned this type.
Then look for User Types granted through membership. These can be identified by the value 'general (with membership only)' in the 'Category' column. These are all custom types that correspond to Individual Membership Types and grant access to the Members area, including areas developed exclusively for use by certain types of members. If you need to understand which Membership Type assigns this User Type, see Manage Individual Membership Types.
A user's access level is primarily determined by which types are assigned to the user or the user's company, and which roles are present in the user's role cache. A user may have multiple instances of the same role in their role cache, indicating they have been assigned more than one type that confers the same role.
User access in Kavi Groups primarily depends upon whether the user has roles and types required to access this area, whether the user belongs to any groups, and which Group Role the user is assigned. For more information, see the Kavi Groups help.
Access to Kavi Mailing List Manager mailing lists is based on whether the user is subscribed or not. For more information, see the Kavi Mailing List Manager help.
Access to other Kavi products, such as Kavi Showcase and Kavi Status Tracker, is set in those applications. See the application help for more information.
Use the Manage a User tool to view the user's role cache. Assuming you have familiarized yourself with the default roles, you should be able to recognize those installed by Kavi Members immediately. These are listed in Kavi Members Default Roles.
If there are default roles installed by other applications, they are documented in the help for that application. For more information roles, Super Admins can click the View Access Configuration link or to the Manage Roles tool. In Manage Roles, The 'Origin' column shows whether the role is custom or was installed by an application. If installed by an application, this column contains the name of the application in the form 'name_app' (e.g., 'members_app', 'showcase_app'). If the name is 'korg_base', the role was installed by the base software that underlies all Kavi applications. If the role has the term 'Editor' or 'edit' as part of the name, it provides Kavi Edit access.
Your site may also include custom roles created specifically to grant access to custom areas or tools. Descriptions are available through either the View Access Configuration or Manage Roles tools.
This question isn't easy to answer. question can only be answered by an administrator who knows the user's Purpose and whether the user holds any special positions in relation to the organization. The administrator needs to understand the organization's classification and access system (as encoded in its types and roles) to determine whether the user has been assigned the right types. The answer is specific to the organization and to the user, but here are some pointers.
If you are troubleshooting this question, be sure you focus on the available data and be leery of other's interpretations as to the possible source of the access "problem." However well-intentioned, interpretations tend to obscure the facts and throw the troubleshooter off-track. Make sure you start off on the right track by collecting the facts and examining them objectively. If you don't have enough information to troubleshoot the problem, ask the reporter for more specifics.
-
If a user isn't able to log into the site and thinks they should be able to, eliminate the most common and easily identifiable cause: the user is 'inactive'. Look up the user in the Manage a User tool. If this individual's Status is 'inactive', you have found the reason they can't access the site.
If you need to know why the user has been flagged as 'inactive', check to see if their Purpose is Individual Member and they have an expired membership (or their Purpose is Company Representative and they belong to a company with an expired membership). Lapsed membership is the most common reason for deactivation. If the user is inactive but has a different purpose, click 'View Activity History' and look for 'Deactivated' in the 'Activity Type' column.
If the user expects to have access to areas, lists or tools that aren't available to all users, look to see whether the user has permissions for the area or tools they were trying to access.
What is this user's Purpose: an individual member, a representative of a member company, an organization staffer or administrator?
Is this person an individual member?
If so, do they need any permissions beyond those usually granted through membership? For instance, is this individual an officer in the organization? Assign the User Type that adds just the level of extra access they need. Ideally, this is a custom User Type designed specifically for individuals who hold this position.
Does this person need permissions ordinarily granted through membership but there is some question about whether these types have been assigned? Look up their membership and be sure it is current. If it is, look up the membership type and see which types it confers. Now look up the user and be sure these types are assigned. If any are missing, Super Admins may assign the missing types by editing this user through the Upload Data tool.
Conversely, this person's permissions may be too high if they have downgraded their membership (although types assigned through the previous membership should have been automatically revoked, so this is rare) or if they recently resigned from a special position in the organization. In these cases, they may have been manually assigned administrative or editorial types that should now be revoked.
Is this person a representative of a member company?
If this person is a regular member company representative, they should have inherited roles granting access to the Members area through the Company Type assigned to their company.
If this individual is primary contact for their company, they should be assigned the 'Primary Contact' default Contact Type.
If this person holds other special positions as company representative, they should be assigned whichever Contact Type confer the roles they need to perform their duties. If this is a standard position in the organization, there should be a Contact Type created specifically for this type of representative.
Conversely, this person's permissions may be too high if their company has downgraded their membership (although types assigned through the previous membership should have been automatically revoked, so this is rare), they have left the company with which they were associated, or they recently resigned from a special position in the organization. In these cases, they may have been manually assigned administrative or editorial types that should now be revoked.
Is this person organization staff or administration?
This person may have inherited roles granting access to the Members area through the Company Type assigned to their company.
Other roles this person requires need to be granted through User Types. Depending on the position this person holds, they may be assigned one or more of the privileged default User Types, especially if the individual performs multiple functions for the organization. Ideally, these types should be correlated to standard positions in the organization and provide only as much access as this position needs.
Conversely, this person's permissions may be too high if they have assumed a different set of duties. If they have left the organization, their Status should be set to 'inactive'. Be sure to add an activity note explaining the reason you deactivated this user for future reference.
Before adding access, determine what additional access is appropriate for this type, user or company. See Are this user's access privileges correct? for pointers. The section addressed to Super Admins includes suggestions for adding roles to existing types and when it might be better to create new types. The section for Organization Admins discusses how to add access by assigning types that already exist.
Remember that the primary control over user access is the Status switch. If this is set to 'inactive', the user will not be able to access any protected parts of the Web site, no matter which roles are in their role cache.
Super Admins
Super Admins can edit the list of associated roles for all types, even default types. The most common reason to add new roles to default types is to add custom roles that grant access to custom tools or areas of the Web site. With the exception of adding custom roles, default types should rarely require editing.
New types should be created anytime there is a position in the organization that doesn't have a corresponding type. This especially includes User Types that correspond to the organization's leadership structure, administration and staff. Each type should grant exactly the privileges required by a specific position and no more. Additional privileges can always be granted to just those users who need them by layering on other types that reflect these additional responsibilities.
Organization Admins
Individual members should have acquired basic Members Area access through types assigned through membership. Types in the 'General (with membership only)' category cannot be assigned independently of membership. If for some reason these types haven't been assigned correctly, a Super Admin will have to correct the situation. If this member has a special position in the organization, assign whatever additional User Types reflect this position and confer the access necessary to perform the responsibilities of this position.
-
Member company representatives should have acquired basic Members Area access through types assigned to their company through membership. Representatives who hold special positions such as Primary Contact acquire additional access by being assigned whichever Contact Type corresponds to this position. Representatives who hold multiple positions can (and should) be assigned multiple types.
Whenever a new person takes over responsibilities from an administrator, staff person or company representative, be sure to revoke any unneeded permissions from the user who formerly held this position. See the instructions for Organization Admins on how to revoke user access.
-
Staff and Administrators may acquire basic site access through Company Types assigned to their company, but this isn't always the case. These users acquire the additional access they need by being assigned User Types that correspond to their job descriptions. Newer, smaller organizations may rely almost exclusively on highly privileged default user types to grant permissions to these users. Organizations with a larger administrative staff will evolve towards more specialization of responsibilities, and add finer-grained custom types with a more discrete level of access privileges. As always, assign the custom User Type created just for that position or whichever default User Type grants the necessary privileges but no more.
Whenever a new person takes over responsibilities from an administrator, staff person or company representative, be sure to revoke any unneeded permissions from the user who formerly held this position. See the instructions for Organization Admins on how to revoke user access.
The primary control over user access is the Status switch. If you need to disable a user's or company's access to the site instantly, use the Change User Status tool or Change Company Status tool and set the status to 'inactive'. The user will not be able to access any protected parts of the Web site, no matter which roles are in their role cache. Setting a company's status to 'inactive' will set the Status of every user who belongs to that company to 'inactive'. Deactivation doesn't revoke any types that have been assigned, so all that has to be done to restore access later is to reset the company or user Status to 'active'. For future reference, be sure to add an activity note explaining the reason you deactivated this user or company.
The section addressed to Super Admins includes suggestions for removing roles from existing types and when it might be better to create new types with a lower level of privileges. The section for Organization Admins discusses how to revoke access by removing types that already exist.
Super Admins
Super Admins can edit the list of associated roles for all types, even default types. The most common reason to remove roles from default types is to remove custom roles that grant access to custom tools or areas that are no longer used. With the exception of removing custom roles, roles associated with default types should rarely require editing.
Custom types should be created anytime there is a position in the organization that doesn't have a corresponding type that conveys the correct level of access. This especially includes User Types that correspond to the organization's leadership structure, administration and staff. Each type should grant exactly the privileges required by a specific position and no more, since additional privileges can always be granted to just those users who need them by layering on other types that reflect these additional responsibilities. If you have a custom type that grants a higher level of access than the corresponding position requires, you can edit the roles associated with that type to adjust the access. If you find that most (but not all) users who have been assigned a custom type require less access than the type confers, you have two options. You can downgrade the access associated with the type by removing roles and assign additional types associated with those roles to users who require extra access, or you can create a new type with less access and reassign users who don't need the higher level of privileges conferred through the current type.
Removing roles from a Company Type will affect the access of every user who belongs to a company that has been assigned that type.
Organization Admins
Unlike other types, User Types and Company Types categorized as 'General (with membership only)' cannot be assigned or revoked manually. Although you can remove these types by deleting the membership, it is usually easier to revoke access by switching company or user status to 'inactive'. Deactivating a company or deleting a company membership will affect the access of everyone who belongs to that company. Always add an activity note when deactivating a member in case the member questions the deactivation or wants to be reactivated at some future date.
Removing a Company Type with roles from a company will revoke these roles from every user associated with this company.
If you need to replace a more privileged Company Type with one that has lower privileges, be sure to add the new type as you remove the old to minimize disruption to these companies' users. Use the Edit a Company tool and on the Admin Info step, be sure to check the new type and uncheck the old type before clicking 'Save' to commit both changes at once.
To remove access from an individual member, member company representative, organization staff or administrator, use the Edit a User tool. On the Admin Info step, uncheck any types you want to remove.
Super Admins
Keep a streamlined set of types and roles by deleting types or roles when they are no longer required.
As your organization grows and changes, you may add types for new positions. It is easier to determine, add and revoke user privileges when privileges are conveyed through just a few types.
It's a good idea to generate a report whenever significant changes are made to the organization's membership or user classification system. If a new membership type is created or an existing type is altered, check to make sure members have the right types assigned. If the list of roles associated with an existing type is altered or a new type is created, see whether this type is assigned to users who should have it and absent from the records of users who should not have it.
Organization Admins:
Whenever a person changes positions in relation to the organization, check the types they have been assigned against their new responsibilities. For example, a company representative designated as Primary Contact may have performed additional tasks such as Showcase Company Editor. Revoking the Primary Contact type won't necessarily affect these other types. If the new Primary Contact will be assuming these additional duties, you may manually remove the appropriate types from the former Primary Contact and assign them to the new Primary Contact.
It's a good idea to generate reports whenever a major change occurs or just periodically to keep tabs on which users have been assigned privileged types and remove any types from users who should no longer have these types.
|
|
 |
|
| Chapter 17. User Types |  |
Chapter 19. Company Representative Signup |