This blog describes the permission’s functionalities that exists in Quality Center. The first thing you have to be aware when customizing a Quality Center project is that permission settings are not defined in a single location but are spread in different parts of the customization sections. You might wonder why such a decision has been made? Even though, the location of these settings have some “reasonable” sense, I believe this complexifies the tasks of securing access to the project data.

Anyway, this is how it is so let’s start examining these settings.

All the security settings are defined in the Customisation (accessible through Tools > Customise…).

The different sections where you can affect user’s permissions are:

• Set Up Project Users
• Set Up Groups
• Customize Module Access
• Set Up Workflow
• Script Generator – Add Defect Field Customization
• Script Generator – Defect Details Field Customization
• Script Editor

Let’s first start with setting up the Group.

Set Up Groups

On a fresh project, there are always 5 default groups that are already defined:

• Developer
• Project Manager
• QATester
• TDAdmin
• Viewer

These groups cannot be customized and cannot be removed from the project. In order to tailor the group permissions to your project, you need to create new groups. With these new groups, you will be able to customize their settings. When creating a new group, you need to indicate from which group you want to duplicate the initial settings. This can be useful especially if your new group has similar settings from another group.

Once created, you can amend its settings by selecting Change permissions. This will bring a new window divided into tabs for each Quality Center module:

• Requirements
• Business Components (optional)
• Test Plan
• Test Lab
• Defects
• Administration (customization module permissions)

For each module you will find similar settings where you can allow (if checked) or disable (unchecked) permissions for different aspects of the module.

There are usually 3 actions Add/Modify/Delete which gives you control on a group basis.

For the Delete action, you can specify that only the owner can delete the object (‘Can be deleted by owner only’ checkbox).

For the Modify action, you can even define finer rules. For each field, you can restrict modification permissions to the owner only (‘Can be modified by owner only’ checkbox) and, for fields defined by lists, you can specify transition rules (i.e. define a transition workflow). This last point is particularly interesting for workflow based transitions such as Status where the designer wants the user to follow a predefined path (for instance, a defect Status cannot be set as Fixed unless the testing team has validated it beforehand by setting its Status as Validated).

For the Test Plan, Test Lab and Defect tabs, you may have noticed a “Data-Hiding Filter” link. These are extra security settings and will bring another window with further customization settings.

First, you can set filtering conditions. By defining a filter, you limit the visibility scope a group has. As an example, imagine you have different teams who are accessing a QC project:

• Team 1: this team have access to some confidential technology and consequently is not accessible to everyone.
• Team 2: these are the outsourced testers who can log defects

To separate the defects that are confidential from the one that are not, a field called “Confidentiality Grade” has been created and this field contains 2 values “1-High” and “2-Low”.

If you are defining a user group for the Team 2 then you set a fiter for the “Confidentiality Grade” field with “2-Low” as the filter. By doing this, any user that is only part of this group will not see any defect with grade “1-High”.

Secondly, you can also hide fields from the user. This prevents a user from seeing values he shouldn’t.

Set Up Project Users

This customization module defines the list of users who are allowed to log into the project. Each user can be part of 1 or more group. Consequently, the user inherits the permissions from the groups he or she is part of. Imagine that a group A has access only to Defect Type 1 and a group B has access only to Defect Type 2 then any user who is part of group A & B will have access to both Defect Types (i.e. 1 and 2).

By default, when a user is created, it belongs to the Viewer group. This group has no modification permission but can see everything. If you want to restrict visibility access to some users, then it is advisable to disable the Viewer group. This will avoid having users part of the Viewer group.

To disable this group, you need to add a chunk of script in the workflow:

Function Project_CanLogin(DomainName, ProjectName, UserName)

If User.IsInGroup(“Viewer”) Then

MsgBox “Your security settings are incorrectly defined, access to the project is forbidden.” & vbNewLine & _

“Please, contact your project administrator!”

Project_CanLogin = False

Else

Project_CanLogin = True

End If

End Function

Customize Module Access

In this part, you can separate groups which have access to the Defect module only and groups which have access to all the modules. When working with third party, you may want them to be able to log defects but not to see your tests, tests results and requirements.

Set Up Workflow

When setting up the workflow, you can use some automated script generator. There is one for customizing the display when adding a new defect and another when editing an existing defect. Both do work the same way.

With the script generator, you can customize a) the fields that will appear, b) the order which they will appear, and c) on which page they will appear (page = tab). And this customization can be done on a group basis.

Personaly, I don’t like using this feature as it generates hundreds of lines of script when you have projects with a lot of fields and groups. Instead, I write my own code using the Script Editor.

Script Editor

The Script Editor is the place where you have the freedom of modifying the behavior of Quality Center in several occasions. We have already seen that we can forbid users to log into the project.

In the Script Editor, the different events that might occur are splitted according to the Quality Center module they relate which gives 6 sections:

• Common script: a few events that go nowhere else
• Requirements module script
• Test Plan module script
• Test Lab module script
• Manual Runner script
• Defects module script

For each section (except common script), you will find similarities. Whenever you see <ModuleName>, you will need to replace it with the name of the module (Defects, ManualRun, TestLab, TestPlan and Requirements). The <Object> should also be replaced by the object type of the module (e.g. Bug for the Defect module). The following events exist:

• <ModuleName>_ActionCanExecute: this event is raised when an action is performed in a module. Please note that not all actions raise this event. For instance, when you press Run in a Test Set, the event is raised with an actionName equal to ‘act_run’. However, if you change the Test Set Properties, no event will be raised.
• <ModuleName>_EnterModule: Raised when a user moves to the module <ModuleName> (like moving from the Requirements to the Defect module)
• <ModuleName>_ExitModule: Raised when a user moves away from the module <ModuleName>
• <ModuleName>_<Object>_New: Raised when a new <Object> is created
• <ModuleName>_<Object>_MoveTo: Raised when an existing <Object> is selected
• <ModuleName>_<Object>_FieldCanChange: Raised when a field value is about to be changed
• <ModuleName>_<Object>_FieldChange: Raised after a field value has been changed
• <ModuleName>_<Object>_CanPost: Raised before a new <Object> is posted
• <ModuleName>_<Object>_CanDelete: Raised when an <Object> is about to be deleted
• <ModuleName>_<Object>_AfterPost: Raised after a new <Object> has been posted

There are other events which are specific to each module.

Some events expect a boolean return value that determines if the change is accepted or not. For instance, the Defect_Bug_FieldCanChange event will validate the change only if it returns true. Otherwise, the user change is cancelled and the previous value is restored. This is useful for imposing a specific workflow:

Function Defects_Bug_FieldCanChange(FieldName, NewValue)

If FieldName = “BG_STATUS” Then

OldValue = Bug_Fields.Field(“BG_STATUS”).Value

If OldValue = “New” And NewValue = “Open” Then

Defects_Bug_FieldCanChange = True

ElseIf OldValue = “Closed” And NewValue = “Open” Then

Defects_Bug_FieldCanChange = True

Else

‘ Any other transition is denied.

Defects_Bug_FieldCanChange = False

End If

Else

Defects_Bug_FieldCanChange = True

End If

End Function