Consider the following case: there are many users in a defect database. These users may come from different teams with an interest in a variety of different projects. To avoid confusion and unexpected operations within the system, the IBM® Rational® ClearQuest® administrator may need to isolate each user's records, so that only the record owner can view and modify his or her own record. If we classify these users by project, then, from a project-by-project point of view, the defect database appears to be unique for each user and each project.

This article illustrates how a ClearQuest administrator can isolate defect records by submitter. It provides step-by-step details on the procedure for customizing your database, and includes some hooks on how to control access rights to certain fields.

Introduction

ClearQuest is a powerful tool for change management in software development. It is highly customizable, which enables users to control their different change management processes flexibly. ClearQuest also provides some predefined templates that will gradually introduce you to the nuances of the tool, beginning with some change management best practices.

For example, when you apply one of the standard templates to administer your change management processes, all team members can by default query all records in the database. This may cause your team confusion, or it may result in some unexpected or incorrect operations -- especially when you have several projects within one database. You may want to isolate these records by owner, project, role, or group. ClearQuest provides a mechanism called Security Context to help you achieve this goal.

In my example, I use TestStudio as the template, and explain how to customize this template to isolate defect records by submitter. The general steps are as follows:

1. Define your isolation policy, and then create proper groups.
2. Create a security context record type.
3. Modify the record type for which you want to enable access control, and add a reference field.
4. Compile some hooks, if needed.
5. Apply the template to the user database and do some presets.

Note: this method is not limited to defect records; it can be applied to any record type to which you want to control access. The following scenario, however, will concentrate on defect management.

Back to top

Detailed Steps

In this scenario, the testers in a project can only view and modify their own submitted records, but members of a test manager group can view all of the records. As a tester, each time you submit a defect, the security context field of the defect is automatically set to you as the owner. Only the ClearQuest administrator can view and modify the security context record type.

This example assumes you are familiar with the ClearQuest customization procedure -- I will walk through the steps, but not the specifics of what is happening behind the scenes. If you are new to this process, please review your ClearQuest documentation regarding the customization procedure.

1. First of all, you need to define proper groups with the ClearQuest User Administration tool. I usually define a group for each tester, and then create a Test Manager group. In a sense, these groups represent specific roles in your project definition. For example, Figures 1-5 show details about my defined groups:

The groups xiaming, yangrong, zhanghan, yangrongwei, and gengxueping are tester groups for individual testers, respectively. The TestManager group is for the Test Manager role.

You can also set up a Guest group definition through which someone who is not a regular user on your project can access those defect records, if authorized by the ClearQuest Administrator.

This sample definition of one tester group includes the member groups Guest and TestManager.

2. Open ClearQuest Designer, log on to your target schema database, and check out the TestStudio template to edit. Add a new stateless record type called ACL (this step of the process is illustrated in Figures 6-11 following). This record type is used as the security context record type.

3. Modify the default Defect record type to add a new field to the defect record type. This field is used as a reference to the security context record, as shown in Figures 12 and 13.

4. To automatically isolate defects, add a default value hook onto the reference field. Although ClearQuest supports two kinds of script languages (VBScript and Perl), note that the following script examples use Perl:

sub acl_DefaultValue {

   my($fieldname) = @_;

    

   my $session;

   my $username;

    

   $session = $entity->GetSession();

   $username = $session->GetUserLoginName();

    

   $entity->SetFieldValue($fieldname, $username);

}

5. Add a permission hook onto the reference field to set access control when changing a defect record.

sub acl_Permission {

   my($fieldname, $username) = @_;

   my $result;

    

   my $userGroups, $sessionObj;

   my $AuthorizedUserGroup = "SuperAdmin";

 

   # By default, set this field readonly

   $result = $CQPerlExt::CQ_READONLY; 

	

   $sessionObj = $entity->GetSession();

   $userGroups = $sessionObj->GetUserGroups();

 

   if(!@$userGroups) {

      $result = $CQPerlExt::CQ_READONLY;

   } else {

      foreach $strAnGroup (@$userGroups) {

         if ($strAnGroup eq $AuthorizedUserGroup){

            $result = $CQPerlExt::CQ_OPTIONAL;

            last;

         }

      }

   }

   return $result;

}

6. Add an access control hook on the actions of the defect record type. What action this hook uses depends on your defect management process definition. In my example, I add this hook on the actions Modify, Delete, Duplicate, and Unduplicate. To better maintain and reuse code, I use record scripts to enhance code reusability.

An example of calling code in the access control hook of an action:

sub Defect_AccessControl {

   my($actioname, $actiontype, $username) = @_;

   my $result;

    

   my $params = 

$actioname."\n".$actiontype."\n".$username;

   $result = $entity-

>FireNamedHook("RS_AccessControl",$params);

   return $result;

}

An example of calling code that is a record script called RS_AccessControl:

sub Defect_RS_AccessControl {

   my($result);

   my($param) = @_;

   # record type name is Defect

 

   if (ref ($param) eq "CQEventObject") {

      # add your CQEventObject parameter handling 
code here

   } elsif (ref (\$param) eq "SCALAR") {

         $sessionObj = $entity->GetSession();

		

         @params = split '\n',$param;

         my $username = $params[2];

 
         $fieldInfo = $entity-

>GetFieldValue("Submitter");

         $strSubmitterName = $fieldInfo-

>GetValue();

	

         # test if the user belongs to group 
"TestManager"

         $userGroups = $sessionObj->GetUserGroups();

         $FlagYes = "yes";

         $FlagNo = "no";

         $AuthorizedUserGroup1 = "TestManager";

         $AuthorizedUserGroup2 = "SuperAdmin";

 

         $flag = $FlagNo;

         if (!@$userGroups) {

            $flag = $FlagNo;

         } else {

            foreach $strAnGroup (@$userGroups) {

               if ( ($strAnGroup eq $AuthorizedUserGroup1) ||

                  ($strAnGroup eq 

$AuthorizedUserGroup2) )

               {

                  $flag = $FlagYes;

                  last;

               }

         }

      }

 

      # test if the user is same as the 

submitter or belongs to group "TestManager"

      if (( $username eq $strSubmitterName)||($flag eq $FlagYes)){

         $result = 1;

      } else {

         $result = 0;

      }

   } else {

         # add your handling code for other type parameters here, for example:

         # die("Unknown parameter type");

      }

      return $result;

}

7. Modify access control of all actions on the ACL record type with user groups, as shown in Figure 14.

This shows that only members in the "SuperAdmin" group can operate on the ACL record type.

8. Check in the schema and apply this design to your user database.
9. Finally, the ClearQuest administrator needs to manually add some security context records, which are associated with each tester group (Figure 15).

Note: in this design, the ACL record name should be exactly the same as the submitter's userid. For example, in Figure 15, if a submitter's userid is xiaming, then the corresponding ACL record name is also xiaming.

OK, that wasn't so hard, was it? Now you can try the design for yourself to see if the defect records are properly isolated by submitter. If the system is not accurately isolating the defects, retrace the steps and try again. Good luck!

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Detailed Steps
• About the author
• Comments

Next steps from IBM

• Try: Rational ClearQuest
• Demo: Create customized queries with IBM Rational ClearQuest
• Webcast: Tips on achieving global IT efficiency through collaboration, automation, and project insight
• Briefing: Quality driven software delivery
• Buy: Rational ClearQuest

My developerWorks community

Dig deeper into Rational on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers