This article focuses on scripts for these purposes:
- Allowing only few people to rename or move files between source-controlled folders, but still restricting everyone from deleting any file.
- Allowing delivery of only one Unified Change Management (UCM) activity at a time from the development stream to the integration stream.
- Implementing different actions for separate user databases that point to the same schema.
You can use these scripts in these situations:
- The first script can be applied in any IBM® Rational® Clearcase environment, regardless of whether it is base or UCM setup.
- The second script can be used only in UCM environments.
- The third script (which is IBM® Rational® ClearQuest® database-related) should be used in cases where there is more than one user database pointing to the same schema but you still need to differ with some of the data, such as choice list, hook permission, record type visibility, and so on.
The sections that follow provide detailed descriptions of all three scripts.
Restrict rename and move operations
Maintaining configuration items within a secure repository is one of the main tasks of software configuration management. You should not allow deleting any artifact unless it is really necessary to do so.
It is a common practice to put a pre-operation trigger for the Rational ClearCase Rmname operation to ensure that no one is able to delete any artifact (un)intentionally. But when such a trigger is implemented, it restricts even the Rename and Move actions, because, internally, they invoke Rmname operations only.
Another view could be that configuration identification is an important aspect of configuration management. So, after the artifacts are identified and naming conventions are fixed, care should be taken that artifact names do not change often, and there should be control on rearrangement of files between folders. Otherwise, it could lead to confusion among team members about the exact path of the artifact.
Keeping this in mind, the following trigger script gives file rename and move permission to only specific users, and they are mentioned in the script. At the same time, file removal permission is still restricted for allusers.
Listing 1. Restrict_Rmname_Trigger.pl script
#! /usr/bin/perl
$clearcase_user = $ENV{CLEARCASE_USER};
chomp($clearcase_user);
$pop = $ENV{CLEARCASE_POP_KIND};
$match = Check_user();
if ($match == 1)
{
# print "User-id matching. Has permission to go ahead with the trigger \n ";
if ($pop ne "lnname")
{
exit 1;
}
else { exit 0; }
}
else
{
# print "User does not have permission \n";
exit 1;
}
sub Check_user
{
@exempted_users = (‘vivek.pandey','user.alpha','user.beta');
$result = 0;
foreach $i(@exempted_users)
{
if ( $i eq $clearcase_user )
{ $result = 1;
return $result;
}
}
return $result;
}
|
In this script, a Perl procedure, check_user(), matches the user ID with the existing list and returns the result if the user has permission to perform move or rename operations.
You need to use the ClearCase CLEARCASE_POP_KIND environment variable to decide whether a user has invoked a file-delete or move operation. If any user invokes a delete operation, the script exits without comparing the user IDs, thus restricting the delete operation.
The script in Listing 2 should be called while defining the trigger inside ClearCase VOB.
Listing 2. Script to call for defining the trigger
Cleartool mktrtype –element –all –preop rmname –execwin “ccperl Restrict_Rmname_Trigger.pl” No_Rmname |
Note:
While defining the triggers, we used the ccperl compiler, which is included with ClearCase, so that there is no need to install an appropriate Perl version separately.
Allow only one UCM activity in a single delivery from a development stream
In UCM, when you deliver some activity from development stream to integration stream, UCM creates one integration activity on the integration stream per delivery operation.
Which means, if you deliver more than 1 activity from development stream to integration stream in one go, there will still be single delivery activity created on the integration stream.
Assume a case where, there are multiple levels of check before delivering any work; hence there are multiple streams which are owned by different roles. Consider case in Figure 1.
Figure 1. Sample stream strategy in UCM
In this situation, when a developer working on multiple tasks delivers all work spread across multiple UCM activities into the Defect Validation stream, UCM creates a single delivery activity in the target stream for any successful delivery.
Consider a case where the release lead okays only a subset of activities (two out of the four delivered) to be integrated into Integration stream. In that case, it is a challenge to pick only the activities that you want to deliver, because the activity present on the Defect Validation stream also contains work that you do not want.
As one of the solutions, there could be a process set where the user should deliver only one activity at a time. But there is no guarantee that all users will follow it 100% of time, especially when the release date is nearing and there is pressure to deliver lot of work.
To enforce such a process (deliver of only one activity at a time), you can use the trigger script, Deliver_only_one_actvity.pl, shown in Listing 2..
Listing 3 shows the actual code.
Listing 3. Trigger script
#! /usr/bin/perl
my $from_stream = $ENV{CLEARCASE_SRC_STREAM};
# `clearprompt proceed -prompt $from_stream -prefer_gui`;
if ($from_stream =~ /Development_Stream/)
{
$delivered_acts = $ENV{CLEARCASE_DLVR_ACTS};
@activities = split(/\s/,$delivered_acts);
$no_of_activities = scalar(@activities);
# `clearprompt proceed -prompt $no_of_activities -prefer_gui`;
if ($no_of_activities gt 1)
{
`clearprompt proceed -prompt "You can Deliver only one activity at a time from
Development Stream" -pefer_gui`;
exit 1;
}
}
|
Here, you use the CLEARCASE_DLVR_ACTS environment variable to determine how many UCM activities have been selected to deliver from development stream. If no number of activities turns out to be greater than 1, then it exits and does not proceed with delivery.
Note:
The from_stream variable is used to determine the stream on which such restrictions should be applied.
This script should be called while defining the trigger in the UCM project VOB.
Listing 4. Defining the Trigger to allow deliver only one activity at a time
Cleartool mktrtype –ucm –preop deliver_start -execwin “ccperl Deliver_only_one_Activity.pl” Deliver_Only_One_Activity |
Enforce separate implementation for clearquest user databases
Often, there are multiple user databases pointing to same ClearQuest schema. For example, one project development team might be catering to defects or change requests (CRs) coming in from different customers.
For maintaining customer privacy, it is often required that there are different user databases for different customers, but that they point to same ClearQuest schema. The defect or CR workflow is the same for all customers.
There might be cases where certain changes are required at the user database levels (adding a value to drop-down menu, different permission for different user databases, and such), yet they are to be implemented by keeping same schema. In such cases, take care that, while fulfilling one customer request, it does not interfere with another customer's requirements. With the same ClearQuest schema, any changes made to it will be reflected in all user databases.
To overcome this, you can use the following code snippet, where part of code is executed depending upon which of the user databases is affected.
Listing 5. Access control hook
$result = 0;
$database = $session->GetSessionDatabase();
my $userdb = $database->GetDatabaseName();
# $entity->SetFieldValue(userdb, $userdb);
if (($userdb eq "TEST1") || ($userdb eq "TEST2") || ($userdb eq "TEST3"))
{
$result = 1;
if (MemberOf("GroupA") == 1)
{
$result = 1;
}
}
|
The script above is an access control hook for the Submit action of the Review workflow. By using this hook, the following criteria have been fulfilled:
- Any user should not be able to submit a Review record to the user databases, other than TEST1, TEST2, and TEST3 databases.
- If a user belongs to ClearQuest GroupA, then only that person should be able to submit a record to any of the three databases.
Note:
MemberOf() is another record script that is used to check the group of the user who is trying to submit the record. However, it is not within the scope of this article to discuss that script.
Here, we are using the ClearQuest GetDatabaseName()API to determine the name of the user database in which the user is trying to submit the record.
This script can be further enhanced to implement other variations, such as different choice lists for different user databases, permissions according to the user databases, and so forth.
See the Resources section for information about ClearCase and ClearQuest.
Learn
- Visit the Rational ClearCase area on developerWorks for technical articles and tutorials.
- Check the ClearCase information center for documentation, tutorials, and other technical information.
- Find answers to terminology questions in the ClearCase Glossary.
- Visit the Rational ClearQuest product page.
- Learn more in the Rational ClearQuest information center.
- Visit the Rational ClearQuest area on IBM developerWorks for technical articles and tutorials.
- Explore the Rational ClearQuest support portal.
- Explore the Rational change and release management library.
- Learn how features such as local and remote access, a proven use model, a wide range of supported environments, transparent access to files, and parallel development support give your team members instant, controlled access to the project assets that they need to create, update, build, reuse, and maintain your software in the software configuration management information center.
- Learn about other applications in the IBM Rational Software Delivery Platform, including collaboration tools for parallel development and geographically dispersed teams, plus specialized software for architecture management, asset management, change and release management, integrated requirements management, process and portfolio management, and quality management.
- Find product manuals, installation guides, and other documentation in the IBM Rational Online Documentation Center.
- Visit the Rational software area on developerWorks for technical resources and best practices for Rational Software Delivery Platform products.
- Explore Rational computer-based, Web-based, and instructor-led online courses. Hone your skills and learn more about Rational tools with these courses, which range from introductory to advanced. The courses on this catalog are available for purchase through computer-based training or Web-based training. Additionally, some "Getting Started" courses are available free of charge.
- Subscribe to the IBM developerWorks newsletter, a weekly update on the best of developerWorks tutorials, articles, downloads, community activities, webcasts and events.
Get products and technologies
- Download the free trial version of ClearCase to try it and decide for yourself.
- Get the trial download of Rational ClearQuest.
- Download trial versions of Rational software.
- Download IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus®, Tivoli®, and WebSphere®.
Discuss
- Join the Rational ClearCase discussion forum to exchange information with your peers.
- Join the Rational ClearQuest Forums and Communities to get and give tips to other developers and testers who use ClearQuest. Subscribe by email, and subscribers can also post by e-mail.
- Check out developerWorks blogs and get involved in the developerWorks community.

Vivek Pandey is a certified Rational software specialist working in IBM Rational Lab services, in India. He has seven years of experience in software configuration management, standards and procedures development, software build and release management, change management training and configuration settings, and implementation in large projects in the banking, financial services, and telecom domains.




