当许多不同的用户共享ClearQuest中的一个缺陷数据库时，管理员可能需要确保只有记录的所有者可以修改他或她自己的记录。本文提供了完成此方法的一个详细的过程。
考虑一下以下情形：在一个缺陷数据库中有许多用户。这些用户可能来自许多不同项目的不同团队。为了避免混乱和系统中的不可预期的操作，IBM® Rational® ClearQuest®管理员可能需要分隔每个用户的记录，因而只有记录的拥有者可以查看和修改他或她自己的记录。如果我们按照项目来分类这些用户，那么从一个个项目的观点来看，缺陷数据库对每个用户和每个项目看起来都是唯一的。
本文阐明了一个ClearQuest管理员可以如何通过提交者来分隔缺陷记录。本文提供了定制数据库过程的一步步的细节内容，并且包括一些如何对某些字段控制访问权限的钩子函数。
介绍
ClearQuest是软件开发中变更管理的一个强有力的工具。它是高度可定制的，使用户能够灵活地控制他们的不同变更管理过程。ClearQuest也提供一些预定义的模板，它们从一些变更管理的最佳实践开始，将逐步地带领你领略此工具的微妙之处，
举例来说，当你应用其中一个标准模板来管理你的变更管理过程时，所有的团队成员缺省可以查询数据库中的所有记录。这可能会引起你的团队的混乱，或者可能会导致某些不可预期或不争取的操作－－特别是当你在一个数据库中有多个项目时。你可能想通过所有者、项目、角色或组来分隔这些记录。ClearQuest提供了一个称为Security Context的机制，来帮助你达成此目标。
在我的例子中，我使用TestStudio作为模板，并解释了如何定制此模板，来按照提交者来分隔缺陷记录。通常的步骤如下：
- 定义你的隔离方针，然后创建适当的组。
- 创建一个security context记录类型。
- 修改你想要进行权限控制的记录类型，并增加一个reference字段。
- 如果需要，编写一些hook。
- 将模板应用于用户数据库，并做一些事先调整。
注意：此方法并不限于缺陷记录；它可以应用于任何你想进行权限控制的记录类型中。然而，下面的场景将集中在缺陷管理上。
详细步骤
在此场景中，一个项目中的测试人员只能查看和修改他们自己提交的记录，但是测试经理组的成员可以查看所有的记录。作为一个测试人员，每次你提交一个缺陷，缺陷的security context字段会自动地将你设置为所有者。只有ClearQuest管理员可以查看和修改security context记录类型。
此例子假定你熟悉ClearQuest定制过程－－我将会浏览一下这些步骤，但不是详述幕后发生了什么。如果你对此过程比较陌生，请查看你的ClearQuest文档中的有关定制过程。
- 首先，你需要使用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。
- 打开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定义 |
- 修改缺省的缺陷记录类型，在缺陷记录类型中增加一个新字段。这个字段用于对security context记录的关联，如图12和13所示。
 |
| 图12：缺陷记录中的ACL字段定义 |
 |
| 图13：将ACL字段的behavior设置为USE_HOOK。 |
- 为了自动地分割缺陷，在关联字段上增加一个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);
} |
- 在关联字段上增加一个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;
} |
- 在缺陷记录的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;
} |
- 使用用户组修改ACL记录类型上的所有action的控制权限，如图14所示。
 |
| 图14：设置控制权限 |
这显示了只有在"SuperAdmin"组中的成员可以对ACL记录类型操作。
- 检入schema，并将此涉及应用到你的用户数据库中。
- 最后，ClearQuest管理员需要手工地增加一些security context记录，这些记录与每个测试人员组关联在一起（图15）。
 |
| 图15：security context记录 |
注释：在此设计中，ACL记录的名字应当与提交者的userid完全一样。例如，在图15中，如果一个提交者的userid是xiaming，那么相应的ACL记录的名字也是xiaming。
不错，这并不是那么难，是不是？现在，你可以自己尝试设计，来看一下缺陷记录是否完全按照提交者分隔开了。如果系统没有准确地分隔缺陷，重新再进行这些步骤。祝你好运！
参考资料
- 您可以参阅本文在 developerWorks 全球站点上的 英文原文。
关于作者
 |
|
|
|
Forrest Xia has authored this article |
|
