Vtiger CRM 5 Test Cases

__USE_EDITOR__ vtiger CRM 5.0.3 Installation - Test Plans vtiger CRM 5.0.3 Dashboards - Test Plans vtiger CRM 5.0.3 Web mail - Working Scenarios

Author: Gopal Date: May 11, 2006 Version: v 0.1 Document Status: In Progress

Contents
[hide]

1 Introduction 2 Test Case 1: Managing Profiles 3 Test Case 2: Managing Roles 4 Test Case 3: Manage Users with Access Privileges 5 Test Case 4: Managing Groups 6 Test Case 5: Setting up Default Organization Fields Access 7 Test Case 6: Setting up Default Organization Sharing Access 8 Practical Test Case 7: Multiple Location Business 9Q&A 10 References

Introduction
The purpose of this document is to help vtiger community testing the security management features incorporated in vtiger CRM 5 Beta release. Organization Level Access Control Precedence Rule is as given below: <a title="Image:Access-precedence.gif" class="image" href="../../index.php/Image:Accessprecedence.gif"><img width="383" height="348" src="../../images/c/c0/Access-precedence.gif" longdesc="/index.php/Image:Access-precedence.gif" alt="Image:Access-precedence.gif" /></a>

Test Case 1: Managing Profiles

Profile function provides access to vtiger CRM modules, sub-modules, and fields in various modules. Users associated to the specific profile can access the functions that are assigned to them. <tbody> </tbody> Important Points:

Global Permission provided in Profile page is only for enabling/disabling Create/Edit/View operations. Delete operation cannot be enabled/disabled through Global Permissions. Global permission in Profile will override the Default Organization and Custom Sharing Rules vtiger CRM security model is organized in such a way that first you can disable access to the data and then gradually enable access to the required data. Create at least 10 different profiles for a better validation. For example, you can create Administrator, Sales Manager, Sales Rep, Marketing Manager, Marketing Analyst, Support Manager, Support Rep, Procurement Officer, Stores Manager, etc.

Steps in Creating a Profile:

Global level access (Edit/View) Module level access (Enable/Disable) Record level access (Create/Modify, Delete, and View) Field level access (Enable/Disable) Utilities level access (Enable/Disable)

Input Data:

Specify Profile Name Enable/Disable Global level permissions Enable/Disable modules Enable/Disable various operations Enable/Disable fields in various modules Enable/Disable utilities in various modules

Expected Result: Profile is created with the defined attributes and ready for assigning to various roles. Limitations: Field-level access privileges are not enabled for the following modules hence they are out of the Security Management Scope:

Reports Dashboards RSS Chat Calendar

Error Conditions: <To be Started>

Test Case 2: Managing Roles

You can define the organization-level hierarchy using Roles. Users at higher hierarchy can access (including CRUD operations) all the records of at lower hierarchy. For example, Sales Manager can access all the Sales Reps' records where as Sales Reps can access only their records. in which data access will be provided according to users' hierarchy in an organization. Note: Before creating a role ensure that you have already created some of the organization level user profiles such as Sales Rep, Sales Manager, Marketing, Support, Stores Operations, Stores Manager, System Administrator, etc. <a rel="nofollow" title="http://static.flickr.com/44/145062908_3e2f5d170f.jpg" class="external free" href="http://static.flickr.com/44/145062908_3e2f5d170f.jpg">http://static.flickr.com/44/145062 908_3e2f5d170f.jpg</a> <tbody> </tbody> Important Points:

Users at higher role can access other users data below their hierarchy provided they have access privilege at profile level. For example, "VP Engineering" can access data of "Manager 1" only if he/she has privilege to access all the modules "Manager 1" has.

Users at the same role cannot access each other's data. For example, VP Engineering cannot access the VP Mktg. data and vice versa. Users at the top of the hierarchy cannot view the data shared to their subordinate users by custom sharing rules Users at the top of the hierarchy cannot view the data owned by the groups of their subordinate users

Steps in creating a Role:

Create a Role from Organization hierarchy chart (Tree View) Assign Profile to Role. You can assign multiple profiles to a role.

Input Data:

Specify Role Name Assign existing profile(s) to the role

Expected Results:

Role is created with a specified profile. If you delete a role, first you must be asked to transfer users related role to another role.

Limitations: <To be started> Error Conditions <To be Started>

Test Case 3: Manage Users with Access Privileges

Immediately after installing vtiger CRM admin user will be created for accessing all the modules. Afterwards admin user can create more users according to the organization requirements. Steps in creating an user:

Create User with Basic Details Select the Role from the Role drop down list

Create Super User (Enable System Administrator Privileges) Activate/Inactivate users Change Password

Input Data:

Fill all the necessary fields Select the Admin status (Active/Disable) Select Role

Expected Results: User is created with specified role and group. If you delete a user, first you must be asked to transfer user related data to another users. Limitations Create Password separately. There is no option to generate password automatically and send to user. Error Conditions: You cannot create a user with a similar name

Test Case 4: Managing Groups

You can create different types of groups (set of users) to manage a set of common records. For example, team selling, team support, event management by group of marketing people, and others. Users associated with a particular group can access the records assigned to a particular group and perform the necessary operations on the records (For example, leads, accounts, trouble tickets, tasks, and events). Steps in creating a group:

Create a group name Associate groups, roles, or users to the group Modules under group scope

<tbody> </tbody> Important Points: The user can view the data of his/her group and group's master group. But cannot view the data of his/her groups

subordinate groups Input Data:

Specify group name Assign Users, Roles, Roles & Subordinates, or Groups to the group

Expected Results:

In user detail view, you can see the groups to which user is associated. If you delete a group, first you must be asked to transfer group related data to another group.

Limitations: <To be started> Error Conditions: <To be started>

Test Case 5: Setting up Default Organization Fields Access

You can control the field (for example, First Name or Last Name in Leads module) display in various modules for the entire organization, so that organization level business process can be customized to some extent from vtiger CRM user interface instead of programmatically defining the fields in various modules. Note: You cannot disable some of the mandatory fields (for example, Last Name and Company fields in Leads module) in modules. Input Data: Enable/Disable fields in various modules Expected Result Default organization-level field access is configured for the organization. Note: Profile level access overrides configurations made in organization level field level access. Limitations

<To be started> Error Conditions: <To be started> putang ina nyong lahat! ang pogi ko diba?

Test Case 6: Setting up Default Organization Sharing Access

You can control the data sharing at organization level. Other users can access the owners' records as per organization-level data (records in various modules) access privilege. You can provide the following types of access levels to vtiger CRM modules:

Private: Only record owner can view the record. Others users including vtiger CRM administrator cannot view the owner's records. Public: Read Only: Other users can only view the records. They cannot perform any operations. Public: Read Create/Edit: Other users can view, create, and modify the records. They cannot delete the owner's records. Public: Read Create/Edit, Delete: Other users can perform all the operations such as, view, create, modify, and delete the records.

Input Data: For each module specify the type of access. Expected Result: The default organization level sharing access is configured. Limitations: <To be Started> Error Conditions: <To be Started>

Practical Test Case 7: Multiple Location Business

(This was written by Don to me on portal.vtiger.com - Ken) Regarding the creation of Roles, you have to create each set of roles for each centre and add all the users in a centre to a single group. For example if you have two centers in one in California and another one in Las Vegas then you have to create two different set of roles like: Regional Manager - California |__ Location Manager- California |__ Senior Worker - California |__ Junior Worker - California Regional Manager - Las Vegas |__ Location Manager- Las Vegas |__ Senior Worker - Las Vegas |__ Junior Worker - Las Vegas

The following problem will arise if you have only one set of role: For example you have roles in the following structure: Regional Manager |__ Location Manager |__ Senior Worker |__ Junior Worker

Now you associate the manager and workers of all region fitness to the following roles. Now when the Regional Manager of California logs into the system, he will be able to view the data owned by the L.Manager, Sen Worker, Junior worker of the all the regions like Las Vegas, Washington, Newyork etc. This is because the user at the top level of the hierarchy can create/view/edit/delete all the data of the user 's present below them in the hierarchy tree. So for your requirement it is advisable to create separate roles for separate centres.

Q&A
Q1. What will happen if I delete profile, role, group, or user from vtiger? Ans: While deleting a role, profile, group, or user first you are asked to transfer data pertaining to the existing user to new user. Q2. Can I assign user to multiple groups? Ans: Yes, you can assign multiple a single user to multiple groups. Q3. Can I assign multiple profiles to a role? Ans: Yes, you can assign multiple profiles to a role. Q4. What is the Precedence rule when multiple profiles are assigned to a single Role?

Ans: The precedence rule is: profile with highest privilege is assigned to the user. For example if you assign Administrator, Sales, Support profiles to a role, the user can access the data with highest Q5. Is there a way to have the "Report to:" a group instead of another person? Ans: No, Users cannot report to group. Q6. If I disable some of the modules, sub-modules, fields in Profile, whether it will reflect in respective user pages or just grayed out. Ans: The respective modules, sub-modules, related lists, and fields are disabled. Q7. Is there any restriction on number of profiles, roles, and groups? Ans: No, there is no restriction on number of users, profiles, roles, and groups.