Users / Staff

User / Staff management is an important part of the design process.  Previously we defined the types of users and the functionality they require.  Now we will take a look at how to create users and grant them access to various portions of the system.

To use the standard .NET Membership, Roles, Profile providers or not to use the standard NET Membership, Roles, Profile providers?  That question took some time to determine exactly the best route to take.  ASP.NET does have a decent out of the box solution that could be used for storing all staff security an profile data, Im not about reinventing the wheel unless its necessary and since the plan for this CRM app is to be easily extended by another developer, Ill leave it to them to reinvent functionality if they see fit.

I decided to use a combination of custom and default providers.  I will utilize the out of the box providers for membership and roles, but will not use the profile provider framework.  Instead what I will reference the userId in my staff record (if the staff is given access to the system).  This option will give the system much needed extendability in the user security department while still leaving a set in stone profile (without requiring a membership user record).  This will also open the door for developers to integrate the CRM with existing applications.  If they already have a solution for providing user security for another web application, they would be able to use the provider of their choice.

The staff record will have a minimal amount of data associated with it for 2 reasons

1. there may already be some type of ERP or Payroll system in place for full employee data
2. The staff records will make use of the custom data fields functionality that I will be introducing later

Basic staff members that have been granted permission to the system will have access to the staff information view and edit pages for their record only unless given permission to view and edit others by a system administrator.  Their information page will display their basic information as well as allow them to change their password.

System administrators will have access to the staff view and edit pages for all staff members as well as access to their security roles setup where they will be assigned to one or more security roles.

Security Permissions & Roles

System administrators will have the ability to create as many user roles as they wish, however simply creating and granting roles to a user is not enough for the app to be flexible.  One role may need to have the ability to view a customer account and add notes, but not be allowed edit the account information.  Another role may not have the ability to even view account information.

In order to fulfill the need to be flexible, the core system will provide a permissions framework that can be extended.  Permissions will be able to be placed into groups (for easier location in the role permission assignment pages), each section that can utilize a permission will check the currently logged in users role or roles to see if that permission has been granted.  The following table will give an idea of how the permission matrix will work

Employee records may be attached to customer records as an account owner.  This will require the need for the system administrator to create a mapping.  To do this in the Security Role configuration, the system administrator will be allowed to specify which security roles should be mapped as account owners.  Any employee that has one of those selected security roles will then be displayed in the Account Owner list.

This concludes the summary of how staff, users, and security will be handled.  In the next part of this series I will map out some of the generic functionality that will exist in many areas of the system.  Such as Custom Data Fields, Appointments, and the User defined home page.