I've given the "permissions trigger" some thought and would like to formalize the requirements a bit. The new trigger will have the following characteristics:
- Since multiple groups will be allowed write access to the vob they will need to be added as additional groups on the vob group list.
- Determination of what users get additional write capability will be on Active Directory groups. IOW you can grant write access to say the CC-PMO group but not specifically to Mike Hrenko who is a member of the CC-PMO group. Additionally CC-PMO would need to appear on the vob group list in this example.
- The trigger will use CLEARCASE_PRIMARY_GROUP to determine what group the user is. This avoids having to do LDAP lookups and it's the way that Clearcase does it anyway. CLEARCASE_PRIMARY_GROUP will not be used verbatim - if it were then anybody would "fake" out the trigger by merely setting CLEARCASE_PRIMARY_GROUP. Instead "creds" will be called to ascertain the effective primary group.
- A permissions element will be created that will contain a list of groups, one per line, that are allowed write access from this folder downward. The vob's initial or primary group owner (CC-TTE in the case of Core_automation) will always have write permission. Furthermore the permissions element should be secured such that only vob's primary group owner can modify it. Otherwise other groups could easily modify the permissions element thus granting write permissions to arbitrary groups.
Let's see an example of how this will work and how the trigger will respond. Let's assume the following directory structure:
Core_automation
Empower CC-EAG-AS, CC-EAG-ESB
Functions CC-EAG-VIP
Results CC-EAG-VMS
Common
Further let's assume that the permissions element is at the Empower level and contains the groups CC-EAG-AS and CC-EAG-ESB. This says that those two groups (as well as CC-TTE as primary group owners of the vob) have write permission (the ability to checkout) elements from Core_automation/Empower downward. Additionally let's say that we have a permissions element at Empower/Functions that lists CC-EAG-VIP and Empower/Results has a permissions element that lists CC-EAG-VMS. The following can be said:
- Members of CC-EAG-AS and CC-EAG-ESB have write permissions to Empower, Empower/Functions, Empower/Results and Empower/Common. Further, if new folders are created under Empower, CC-EAG-AS and CC-EAG-ESB will have write permissions to those new folders as well (IOW the write permissions are inherited by new folders that are created)
- Members of CC-EAG-VIP have write permissions to Empower/Functions and any new folders created under Functions, but they do not have write permissions to Empower/Results nor Empower/Common. Similarly CC-EAG-VMS has write permissions to Empower/Results but not to Empower/Functions nor Empower/Common
The pseudo code for the trigger is roughly as follows. Note that the trigger gets fired during checkout of an element only (it is assumed if the user successfully checked out the element then, at the time, he had write permissions and should be allowed to check in the element):
$vob_group_owner = GetGroupOwner (vob)
$current_group = GetCurrentGroup (CLEARCASE_PRIMARY_GROUP as per "creds")
if (permissions element exists in the current folder) {
if (IsAMember (Parse ($permissions_element), $current_group) {
<allow checkout>
} else {
<recurse to check parent folder stopping at vob root>
<disallow checkout>
}
}