IBM®
跳转到主要内容
    中国 [选择]    使用条款
 
 
Select a scope: Search for:    
    首页    产品    服务与解决方案     支持与下载    个性化服务    
跳转到主要内容

developerWorks 中国  >  Rational  >

定制ClearQuest以通过所有者、角色或组来分隔记录

developerWorks
文档选项

未显示需要 JavaScript 的文档选项


级别: 初级

Forrest Xia, 软件工程师, IBM

2005 年 6 月 23 日

当许多不同的用户共享ClearQuest中的一个缺陷数据库时,管理员可能需要确保只有记录的所有者可以修改他或她自己的记录。本文提供了完成此方法的一个详细的过程。

考虑一下以下情形:在一个缺陷数据库中有许多用户。这些用户可能来自许多不同项目的不同团队。为了避免混乱和系统中的不可预期的操作,IBM® Rational® ClearQuest®管理员可能需要分隔每个用户的记录,因而只有记录的拥有者可以查看和修改他或她自己的记录。如果我们按照项目来分类这些用户,那么从一个个项目的观点来看,缺陷数据库对每个用户和每个项目看起来都是唯一的。

本文阐明了一个ClearQuest管理员可以如何通过提交者来分隔缺陷记录。本文提供了定制数据库过程的一步步的细节内容,并且包括一些如何对某些字段控制访问权限的钩子函数。

介绍

ClearQuest是软件开发中变更管理的一个强有力的工具。它是高度可定制的,使用户能够灵活地控制他们的不同变更管理过程。ClearQuest也提供一些预定义的模板,它们从一些变更管理的最佳实践开始,将逐步地带领你领略此工具的微妙之处,

举例来说,当你应用其中一个标准模板来管理你的变更管理过程时,所有的团队成员缺省可以查询数据库中的所有记录。这可能会引起你的团队的混乱,或者可能会导致某些不可预期或不争取的操作--特别是当你在一个数据库中有多个项目时。你可能想通过所有者、项目、角色或组来分隔这些记录。ClearQuest提供了一个称为Security Context的机制,来帮助你达成此目标。

在我的例子中,我使用TestStudio作为模板,并解释了如何定制此模板,来按照提交者来分隔缺陷记录。通常的步骤如下:

  1. 定义你的隔离方针,然后创建适当的组。
  2. 创建一个security context记录类型。
  3. 修改你想要进行权限控制的记录类型,并增加一个reference字段。
  4. 如果需要,编写一些hook。
  5. 将模板应用于用户数据库,并做一些事先调整。

注意:此方法并不限于缺陷记录;它可以应用于任何你想进行权限控制的记录类型中。然而,下面的场景将集中在缺陷管理上。





回页首


详细步骤

在此场景中,一个项目中的测试人员只能查看和修改他们自己提交的记录,但是测试经理组的成员可以查看所有的记录。作为一个测试人员,每次你提交一个缺陷,缺陷的security context字段会自动地将你设置为所有者。只有ClearQuest管理员可以查看和修改security context记录类型。

此例子假定你熟悉ClearQuest定制过程--我将会浏览一下这些步骤,但不是详述幕后发生了什么。如果你对此过程比较陌生,请查看你的ClearQuest文档中的有关定制过程。

  1. 首先,你需要使用ClearQuest User Administration工具定义适当的组。我通常为每个测试人员定义一个组,然后创建一个测试经理组。在某种意义上,这些组代表了你的项目定义中的特定角色。例如,图1-5显示了关于我定义的组的详细内容:

图1:在ClearQuest中设置组

组xiaming、yangrong、zhanghan、yangrongwei和gengxueping都分别是单个测试人员的测试组。TestManager组是测试经理角色的组。

图2:TestManager组的定义

图3:ClearQuest管理员的SuperAdmin组的定义

图4:定义一个Guest组

如果经过ClearQuest管理员授权,你也可以设置一个Guest组,用于不在你的项目中的用户来访问那些缺陷记录。

图5:为一个单独测试人员设置一个组

这个单个测试人员组的例子包括成员组Guest和TestManager。

  1. 打开ClearQuest Designer,登录到你的目标schema数据库,并检出(check out)TestStudio模版进行编辑。增加一个新的状态无关记录类型,名为ACL(此过程的步骤如下面的图6-11所示)。此记录类型用作security context记录类型。

图6:增加一个新的状态无关记录类型

图7:ACL记录类型的字段定义

图8:ACL记录类型的action定义

图9:ACL记录类型的behavior定义

图10:ACL记录类型的主键定义

图11:ACL记录类型的form定义

  1. 修改缺省的缺陷记录类型,在缺陷记录类型中增加一个新字段。这个字段用于对security context记录的关联,如图12和13所示。

图12:缺陷记录中的ACL字段定义

图13:将ACL字段的behavior设置为USE_HOOK。

  1. 为了自动地分割缺陷,在关联字段上增加一个default value hook。尽管ClearQuest支持两种脚本语言(VBScript和Perl),但是以下脚本的例子使用了Perl:

sub acl_DefaultValue {
   my($fieldname) = @_;

   my $session;
   my $username;

   $session = $entity->GetSession();
   $username = $session->GetUserLoginName();

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

  1. 在关联字段上增加一个permission hook,在改变一个缺陷记录时设置控制权限。

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;
}

  1. 在缺陷记录的action上增加一个access control hook。在我的例子中,我在action Modify、Delete、Duplicate和Unduplicate上增加了此hook。为了更好地维护和重用代码,我使用record scripts来增强代码可重用性。

在一个action的access control hook中调用代码的一个例子如下:

sub Defect_AccessControl {
   my($actioname, $actiontype, $username) = @_;
   my $result;

   my $params =
$actioname."\n".$actiontype."\n".$username;
   $result = $entity-
>FireNamedHook("RS_AccessControl",$params);
   return $result;
}

调用代码的一个例子,其是一个record script,名为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;
}

  1. 使用用户组修改ACL记录类型上的所有action的控制权限,如图14所示。

图14:设置控制权限

这显示了只有在"SuperAdmin"组中的成员可以对ACL记录类型操作。

  1. 检入schema,并将此涉及应用到你的用户数据库中。
  2. 最后,ClearQuest管理员需要手工地增加一些security context记录,这些记录与每个测试人员组关联在一起(图15)。

图15:security context记录

注释:在此设计中,ACL记录的名字应当与提交者的userid完全一样。例如,在图15中,如果一个提交者的userid是xiaming,那么相应的ACL记录的名字也是xiaming。

不错,这并不是那么难,是不是?现在,你可以自己尝试设计,来看一下缺陷记录是否完全按照提交者分隔开了。如果系统没有准确地分隔缺陷,重新再进行这些步骤。祝你好运!



参考资料

  • 您可以参阅本文在 developerWorks 全球站点上的 英文原文


关于作者

Forrest Xia has authored this article




对本文的评价

太差! (1)
需提高 (2)
一般;尚可 (3)
好文章 (4)
真棒!(5)

建议?







回页首


IBM 公司保留在 developerWorks 网站上发表的内容的著作权。未经IBM公司或原始作者的书面明确许可,请勿转载。如果您希望转载,请通过 提交转载请求表单 联系我们的编辑团队。
    关于 IBM 隐私条约 联系 IBM 使用条款