Sun WorkShop TeamWare User's Guide HomeContentsPreviousNextIndex


Chapter 4

Controlling Workspace Access

Sun WorkShop TeamWare allows you to control who can putback files to workspaces by setting permissions and through putback validation. This chapter covers the following topics:

Specifying Permissions

You can grant or deny permissions on a global (see Specifying Global Permissions), group, or individual basis (see Specifying Group or Individual Permissions).

You can grant or deny permission for individual users or groups to perform the following Sun WorkShop TeamWare transactions:

Specifying Global Permissions

To specify global permissions:

1. Start Configuring.

2. Choose File Load Workspaces.

3. Select the workspace in the Load Workspaces dialog box and click Load Workspaces.

4. Click on the workspace to select it.

5. Choose Workspace Properties.

6. Select the Access Control tab in the Workspace Properties dialog box.


FIGURE 4-1   Workspace Properties: Access Control Tab

7. Select an operation and click Edit.

This displays the Access Control Properties dialog box.

8. Select the type of permission you want to allow:

By default, all users have permission to execute the transaction.

9. Click OK.

Specifying Group or Individual Permissions

1. Start Configuring.

2. Choose File Load Workspaces.

3. Select the workspace in the Load Workspaces dialog box and click Load Workspaces.

4. Click on the workspace to select it.

5. Choose Workspace Properties.

6. Select the Access Control tab in the Workspace Properties dialog box.

7. Select an operation and click Edit to display the Access Control Properties dialog box.

8. Click the Specify permissions radio button.

9. In the Name text box, type a user's (or group's) login name.

10. Click the User or Netgroup button to indicate whether it is a single user or a group.

11. Click the Granted or Denied radio button.

12. Click the Insert Before or Insert After button to add the user to the list (or to start the list).

13. Click OK.

The user or netgroup is displayed on the permissions list in the Access Control tab.


Note – The order in which a user appears on the list can have an effect on permissions. If a user is listed as having been both granted and denied permission, Sun WorkShop TeamWare tools use only the first reference. This can occur when you grant access to an individual and deny access to a group that the individual belongs to. In this instance, if the individual is listed first, the individual will have access, if the group is listed first, the individual does not have access.

Protecting Workspaces With Putback Validation

Use putback validation if you want to have more strict control over a workspace. When you turn on putback validation, only putbacks are allowed to the workspace. The user is also prompted for a "password" (Integration Request Identifier) before doing a putback. Configuring does not validate the Integration Request Identifier, but it will pass it on to another program. To validate the Integration Request Identifier, you must write your own validation program. See Invoking Your Own Putback Validation Program. If Putback Validation is turned on, but you do not have your own putback validation script, Configuring always allows the putback. The Integration Request Identifier supplied by the user is recorded in workspace history file and under the heading RTI (Request To Integrate).

TABLE 4-1 summarizes the three Putback Validation modes.

TABLE 4-1   Putback Validation Modes
Mode User Configuring
Putback Validation off (default) Does nothing. Allows all putbacks to workspace.
Putback Validation on Turns on Putback Validation. Requires a "password" (Integration Request Identifier) before a putback is allowed. Password is not validated, merely recorded.
Putback Validation on and passwords checked. Writes putback validation program, turns on Putback Validation, invokes putback validation program. Requires a "password" (Integration Request Identifier) before a putback is allowed. Integration Request Identifier is passed to validation program. Validation program must grant permission before putback is allowed.


SCCS also allows you to require a check-in validation for individual files. See Setting SCCS File Properties.

Turning On Putback Validation

To turn on Putback Validation:

1. In the Configuring Window, load an existing workspace by choosing File Load Workspaces.

2. Click on the workspace to select it.

3. Choose Workspace Workspace Properties.

4. Click the Putback Validation tab in the Workspace Properties Dialog Box (see FIGURE 4-2).


FIGURE 4-2   Workspace Properties: Putback Validation Tab

5. Click Putback Validation On.

6. Click OK.

Invoking Your Own Putback Validation Program

If a validation program is set for a workspace, any putback operation to the workspace will invoke the program that you indicate. If the program fails, then the putback is canceled.
The validation program is not a part of Sun WorkShop TeamWare. You must provide your own putback validation program. A sample validation program is provided in CODE EXAMPLE 4-1.
To invoke your validation program:

1. In the Configuring Window, load the workspace by choosing File Load Workspaces.

2. Click on the workspace to select it.

3. Choose Workspace Workspace Properties.

4. Click the Putback Validation tab in the Workspace Properties dialog box.

5. Click Putback Validation On.

6. Click Putback Approval: Approved by Validation Program.

7. Type the path to your validation program in the Validation Program text box.

8. Click OK.

Sample Validation Program

This is a sample validation program you can use to determine whether you want to allow a putback to a specific workspace. It can be any executable file (shell script, program, etc.) that accepts arguments passed by putback and returns nonzero exit status to deny putback.
The user who wants to do a putback will be prompted for a Integration Request ID and then the validation program will be invoked with the following arguments:

CODE EXAMPLE 4-1 is a program that checks all the arguments and, if successful, returns a zero exit status to allow the putback.

CODE EXAMPLE 4-1   Sample Putback Validation Program 
## Start of sample validation program
#!/bin/sh
##
## Here is the list of users who can perform
## putback to the workspace
##
valid_users="nikm azv builder vvg aar"
##
## Here is the list of Integration Request Ids which
## are accepted
##
P1Bugs="1111111 2222222 1234567 bobs_bug"
##
## Here are the directories which cannot change
##
DirsReady="doc subdir/doc"
##
## Save arguments
##
User=$1
        shift
Parent=$1
        shift
Child=$1
        shift
IRI=$1
        shift
Files=`cat $1`
##
## Validate user
##
isValid="false"
for u in $valid_users
do
   if [ "$User" = "$u" ] ; then
      isValid="true"
      break
   fi
done
if [ "$isValid" = "false" ] ; then
   # invalid user
   echo ""
   echo "*** Validation failed: User $User is not allowed \
        to putback to $Parent"
   echo ""
   exit 1
fi
##
## Validate Integration Request Id (IRI)
##
isValid="false"
for u in $P1Bugs
do
  if [ "$IRI" = "$u" ] ; then
     isValid="true"
     break
  fi
done
if [ "$isValid" = "false" ] ; then
   # invalid IRI
   echo ""
   echo "*** Validation failed: Integration request $IRI \
        is invalid"
   echo ""
   exit 1
fi
##
## Validate files
##
for u in $Files
do
   for uu in $DirsReady
   do
      x=`echo $u | grep $uu`
      if [ "$x" != "" ] ; then
         isValid="false"
         echo ""
               echo "*** Validation failed: File $u \
                    cannot be changed"
               echo ""
               exit 1
           fi
       done
done
##
## Exit 0 - putback is allowed
##
exit 0
## End of sample validation program

Removing Workspace Locks

To assure consistency, the Configuring transactions--Bringover, Undo, and Putback--lock workspaces during these transactions.

If you attempt to bring over files into a workspace that is locked, you will get a message that states the name of the user who has the lock, the command they are executing, and the time they obtained the lock.

bringover: Cannot obtain a write lock in workspace "/tmp_mnt/
home/my_home/projects/mpages"
because it has the following locks:
	 Command: bringover (pid 20291), user: jack, machine: holiday, 
time: 12/02/91 16:25:23
  (Error 2021)

Sun WorkShop TeamWare removes these locks after the transaction is over. Normally, you will not encounter a locked workspace. However, if a transaction encounters problems, sometimes locks stay in place and you can no longer access the workspace. If you are sure no one else is accessing the workspace, but a lock remains, you can remove it manually.


Note – Be sure no one else is modifying the workspace before removing the lock. Removing a lock from a workspace that is currently being modified by another user compromises the integrity of that workspace.

To remove a workspace lock:

1. Make sure no one else is modifying files or performing any transactions in the workspace.

2. In the Configuring Window, load the workspace by choosing File Load Workspaces.

3. Click on the workspace to select it.

4. Choose Workspace Edit Locks.

5. In the Edit Locks dialog box, click a lock to select it.

6. Click Delete.

7. To close the Edit Locks dialog box, click OK.


Sun Microsystems, Inc.
Copyright information. All rights reserved.
Feedback
Library   |   Contents   |   Previous   |   Next   |   Index