當許多不同的用戶共享ClearQuest中的一個缺陷數據庫時,管理員可能需要確保只有記錄的所有者可以修改他或她自己的記錄。本文提供了完成此方法的一個詳細的過程。
考慮一下以下情形:在一個缺陷數據庫中有許多用戶。這些用戶可能來自許多不同項目的不同團隊。為了避免混亂和系統中的不可預期的操作,IBM Rational ClearQuest管理員可能需要分隔每個用戶的記錄,因而只有記錄的擁有者可以查看和修改他或她自己的記錄。如果我們按照項目來分類這些用戶,那么從一個個項目的觀點來看,缺陷數據庫對每個用戶和每個項目看起來都是唯一的。
本文闡明了一個ClearQuest管理員可以如何通過提交者來分隔缺陷記錄。本文提供了定制數據庫過程的一步步的細節內容,并且包括一些如何對某些字段控制訪問權限的鉤子函數。
介紹
ClearQuest是軟件開發中變更管理的一個強有力的工具。它是高度可定制的,使用戶能夠靈活地控制他們的不同變更管理過程。ClearQuest也提供一些預定義的模板,它們從一些變更管理的最佳實踐開始,將逐步地帶領你領略此工具的微妙之處,
舉例來說,當你應用其中一個標準模板來管理你的變更管理過程時,所有的團隊成員缺省可以查詢數據庫中的所有記錄。這可能會引起你的團隊的混亂,或者可能會導致某些不可預期或不爭取的操作--特別是當你在一個數據庫中有多個項目時。你可能想通過所有者、項目、角色或組來分隔這些記錄。ClearQuest提供了一個稱為Security Context的機制,來幫助你達成此目標。
在我的例子中,我使用TestStudio作為模板,并解釋了如何定制此模板,來按照提交者來分隔缺陷記錄。通常的步驟如下:
注意:此方法并不限于缺陷記錄;它可以應用于任何你想進行權限控制的記錄類型中。然而,下面的場景將集中在缺陷管理上。
詳細步驟
在此場景中,一個項目中的測試人員只能查看和修改他們自己提交的記錄,但是測試經理組的成員可以查看所有的記錄。作為一個測試人員,每次你提交一個缺陷,缺陷的security context字段會自動地將你設置為所有者。只有ClearQuest管理員可以查看和修改security context記錄類型。
此例子假定你熟悉ClearQuest定制過程--我將會瀏覽一下這些步驟,但不是詳述幕后發生了什么。如果你對此過程比較陌生,請查看你的ClearQuest文檔中的有關定制過程。
組xiaming、yangrong、zhanghan、yangrongwei和gengxueping都分別是單個測試人員的測試組。TestManager組是測試經理角色的組。
如果經過ClearQuest管理員授權,你也可以設置一個Guest組,用于不在你的項目中的用戶來訪問那些缺陷記錄。
這個單個測試人員組的例子包括成員組Guest和TestManager。
sub acl_DefaultValue {
my($fieldname) = @_;
my $session;
my $username;
$session = $entity->GetSession();
$username = $session->GetUserLoginName();
$entity->SetFieldValue($fieldname, $username);
}
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中調用代碼的一個例子如下:
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;
}
這顯示了只有在"SuperAdmin"組中的成員可以對ACL記錄類型操作。
注釋:在此設計中,ACL記錄的名字應當與提交者的userid完全一樣。例如,在圖15中,如果一個提交者的userid是xiaming,那么相應的ACL記錄的名字也是xiaming。
不錯,這并不是那么難,是不是?現在,你可以自己嘗試設計,來看一下缺陷記錄是否完全按照提交者分隔開了。如果系統沒有準確地分隔缺陷,重新再進行這些步驟。祝你好運!
原文轉自:http://www.anti-gravitydesign.com