Managing mastership in ClearQuest

This section looks at the issues around mastership in ClearQuest.

Local mastership model

The out-of-box behavior is for the originating site to master the records it creates. If your change management process is at the stage where you are just recording changes, or where the approval process is done locally, the defaults work fine.

Manual change of mastership

Just as with ClearCase, you can give mastership away of a record mastered by your site. From the command line, as an ClearQuest administrator:

  multiutil chmaster -fam PLAY -user admin "" tokyo Defect:PLAY00000001

To allow users to give away mastership, modify the schema to expose the mastership field ratl_mastership as shown in Figure 14-6:

Figure 14-6. Adding a mastership field to UCM activity records

[View full size image]

• In ClearQuest Designer, check out the UCM schema you are using for your databases.
  
  
• Add the ratl_mastership field to all activity forms in ClearQuest Designer.
  
  
• Run validation and test the change in a test database.
  
  
• Check in the schema change.
  
  
• At a scheduled time, update the user databases (with users out of system).
  
  
• Replicate to the other sites.
  
  
• Import the replica packet—this will pick up the schema changes.
  
  
• Update the remote database using ClearQuest Designer.
  
  
• Reimport the same replica packet to pick up the user database changes.
  
  

The exposed ratl_mastership field is better than asking the administrator to make the change for you, but it is not a good solution for any systemic requirement for change of mastership. Read on.

Avoiding change of mastership

If the site uses a ClearQuest Web site and you have access to it, you can just access the record directly over the Web. From the ClearQuest database perspective, you are logging in locally. This is a fairly common practice and is very useful for those cases where you just want to add some additional information to the record.

State-based mastership

What if testers are not co-located with developers? What if the project decides that all activities will be triaged in Boston before being assigned? Now you definitely need an automated way to pass mastership around. Here is an example implementation described by Ryan Sappenfield in Rational ClearQuest MultiSite Tips & Tricks and available from developerWorks.

Mastership rule (pseudo-code):

  If (State=Submitted,Postponed,Resolved,Duplicate, or Closed)
      Mastership=Boston
  If (State=Assigned, or Closed)
      Mastership=Replica of Owner

Implement this through a Base Validation Action hook, called set_mastership, as shown in Figure 14-7 with Perl code shown in Figure 14-8.

Figure 14-7. ClearQuest-MultiSite—automating state-based change of mastership

[View full size image]

Figure 14-8. ClearQuest MultiSite—State-based mastership hook

sub Defect_Validation {
my($actionname, $actiontype) = @_;
my $result;
    $sessionObj = $entity->GetSession();
    $state      = $entity->GetFieldValue("State")->GetValue();
    $owner      = $entity->GetFieldValue("Owner")->GetValue();
    $site       = $entity->GetFieldValue("ratl_mastership")->GetValue();
    # check state value
    if ($state eq "Submitted" | "Postponed" | "Resolved" |
            "Duplicate" | "Closed") {
         #set mastership to Boston
         $entity->SetFieldValue("ratl_mastership", "BOSTON");
    }elsif ($state eq "Assigned" | "Opened") {
         #get mastership of the current record owner
         my $userObj        = $sessionObj->GetEntity("users",$owner);
         my $userMastership =
               $userObj->GetFieldValue("ratl_mastership")->GetValue();
         #set mastership of record to match current owner
          $entity->SetFieldValue("ratl_mastership",$userMastership);
    }
return $result;

Follow the procedures described in ““Manual change of mastership” on page 288” to update the schema.