Thursday, September 16, 2010
Tuesday, September 7, 2010
Defining user permissions
This article 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 Customization (accessible through Tools > Customize…).
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.
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 Customization (accessible through Tools > Customize…).
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.
How to become a QC Project Administrator - Roles and Responsibilities
1.Log in to the QC - Site Administration Tool
2.Highlight the Project where the User is to become the Project Administrator
3.Check the Project Administrator Check box "ON" for the User
4.Save and Log Out
5.Log in to the QC Project
6.In the Customization Page, assign the user to the "TD_ADMIN_QTP_Project" Group
Remove the User from the "TD Admin" Group
Note: If the User is no longer a TD Admin of any Project,that user will no longer be able to log in to the Site Administration Tool.
Site Administrator: The Site Administrator allows the user to:
1.Become a QC Administrator of any QC Project
2.Create,Delete,Modify,Disconnect,Remove,Restore,Activate,Deactivate,Copy,Upgrade,....of any QC Project
3.Add Users to QC
NOTE:Once the User is added to QC, the user should be added to a Project in the Project Custmization Tool
4.Disconnect Users from Login Session
5.Update the QC License
6.Configure QC
7.View License usage
Site Administrator Access:
1.From the QC Home Page,Click the Site Administrator Link so that the "Quality Center - Administration" Log in Page Displays
2.Log in Using the Same User Name and Password used to log in to a QC Project
3."Site Projects" Tab is where a QC User can be set as a Site Administrator which allows them to access the "Quality Center - Site Administration" Tool
4.A Tree View of the Domains and Projects within those Domains Display
5."QualityCenter_DEMO" is a built in demo Project that comes with QC
6.Never DELETE "QualityCenter_DEMO"
7.This Project is where users can be set as a "Project Administrator"
Selecting the Project Administrator Check Box for a User in ANY* Project automatically makes a QC User a
a) QC "Site" Administrator
b) A "TD Admin" for Only that Project
8.There are other two Projects in a QC where a User might be set to become a Site Administrator(In Case the QualityCenter_DEMO project is accidentally deleted)
a) QC_MASTER_TEMPLATE
b) QC_EXAMPLE_Structure
9.Setting User as a Project Administrator in the QC-Site Administration automatically assigns the User to the TD_Admin User group for that Project
TD_Admin is a pre-defined QC User Group
User Defined Groups must be used instead of "TD Admin"
This is because QC was Customized to use only User-Defined Groups.
TD_ADMIN_QTP_Project is a user defined Group most equilaent to the TD_Admin Group
10. UnAssigning a User from the "TD Admin" Group will remove the user from being a Site Administrator.But if the User is still assigned to at least on a project as a Project Administrator (TD_Admin),the user can still access the Site Administration Tool
11. It is a good idea to have more than one user as a "Site Administrator" in order to have a backup person
12. It is not a good idea to have a user as a "Project Administrator" of a Project if that User's Position is not to be one,due to many reasons (i.e useless email notifications,accidental deletion of data...)
2.Highlight the Project where the User is to become the Project Administrator
3.Check the Project Administrator Check box "ON" for the User
4.Save and Log Out
5.Log in to the QC Project
6.In the Customization Page, assign the user to the "TD_ADMIN_QTP_Project" Group
Remove the User from the "TD Admin" Group
Note: If the User is no longer a TD Admin of any Project,that user will no longer be able to log in to the Site Administration Tool.
Site Administrator: The Site Administrator allows the user to:
1.Become a QC Administrator of any QC Project
2.Create,Delete,Modify,Disconnect,Remove,Restore,Activate,Deactivate,Copy,Upgrade,....of any QC Project
3.Add Users to QC
NOTE:Once the User is added to QC, the user should be added to a Project in the Project Custmization Tool
4.Disconnect Users from Login Session
5.Update the QC License
6.Configure QC
7.View License usage
Site Administrator Access:
1.From the QC Home Page,Click the Site Administrator Link so that the "Quality Center - Administration" Log in Page Displays
2.Log in Using the Same User Name and Password used to log in to a QC Project
3."Site Projects" Tab is where a QC User can be set as a Site Administrator which allows them to access the "Quality Center - Site Administration" Tool
4.A Tree View of the Domains and Projects within those Domains Display
5."QualityCenter_DEMO" is a built in demo Project that comes with QC
6.Never DELETE "QualityCenter_DEMO"
7.This Project is where users can be set as a "Project Administrator"
Selecting the Project Administrator Check Box for a User in ANY* Project automatically makes a QC User a
a) QC "Site" Administrator
b) A "TD Admin" for Only that Project
8.There are other two Projects in a QC where a User might be set to become a Site Administrator(In Case the QualityCenter_DEMO project is accidentally deleted)
a) QC_MASTER_TEMPLATE
b) QC_EXAMPLE_Structure
9.Setting User as a Project Administrator in the QC-Site Administration automatically assigns the User to the TD_Admin User group for that Project
TD_Admin is a pre-defined QC User Group
User Defined Groups must be used instead of "TD Admin"
This is because QC was Customized to use only User-Defined Groups.
TD_ADMIN_QTP_Project is a user defined Group most equilaent to the TD_Admin Group
10. UnAssigning a User from the "TD Admin" Group will remove the user from being a Site Administrator.But if the User is still assigned to at least on a project as a Project Administrator (TD_Admin),the user can still access the Site Administration Tool
11. It is a good idea to have more than one user as a "Site Administrator" in order to have a backup person
12. It is not a good idea to have a user as a "Project Administrator" of a Project if that User's Position is not to be one,due to many reasons (i.e useless email notifications,accidental deletion of data...)
Subscribe to:
Posts (Atom)