In a previous post I showed how to get the Android Platform source into RTC as components and also how to use load rules to ensure consistency in loading (extracting) the source from RTC. There are a couple of articles on Jazz.net that go into loading content from RTC in excellent detail (https://jazz.net/library/article/1016 and https://jazz.net/library/article/1015). The question then came up on how to set up RTC Project and Team areas to implement a very specific access control scheme for both the SCM and Work Item capabilities for teams doing Android development.
The requirements were as follows:
- 3 Teams (Team1, Team2, Team3) with one team further divided into 2 (or more) sub-teams (Team3.1 and Team3.2)
- Each team should have exclusive read/write access to a set of SCM components it owns
- Each team also may have shared read/write access to a set of SCM components
- For simplicity only two streams with all the components available are to be used but access control to components still needs to be maintained
- Team1 should have exclusive read/write access to its own Work Items
- Team1 may grant read+write access to some of it’s WI’s to Team3
- Team2 only has read/write access to its own Work Items
- Team3 and its sub-teams each has read/write access to its own Work Items and Team2‘s Work Items
- All teams have read/write access to Work Items belonging to the Project Area
Since the Work Item access requirements (5-9) appear to be a little complex let’s look at how that can be implemented first. Here’s what the RTC Team Organization view looks like :
Ignoring the “SCMAccesGroup” Team Areas for now, at first glance the hierarchy doesn’t match the “real” structure of our teams. In particular stashing Team3 and it’s sub-teams as children of Team2 looks bizarre. However (as was pointed out to me by Jorge) when working with RTC’s Work Item Categories, which determine the values of the “Filed Against” attribute, visibility is inherited bottom in a hierarchy. In other words, organising Team3 as a child of Team2will satisfy requirements 7 and 8 in one shot. Here’s what the corresponding Categories are:
So let’s see if this works with a sample set of work items each of which is Filed Against one of the above Categories. A query is set up that simply shows the Summary and Filed Against attributes of all Work Items (no filters).
Here’s what the result of running the query as each of the members of the different teams shows:
Checking the results shows that requirements 5, 7, 8, 9 are satisfied by the configuration so far. To satisfy requirement 6, Bob can simply change the Filed Against attribute for “Task for team 1” to “Team3“, which then makes it visible to Dave, Deb and Marco. Requirement 6 is a little ambiguous though: the current implementation means that once a Team1 Work Item is Filed Against Team3, Team1 loses access to it. What if Team1 still needs to “own” it but also needs to grant access to Team3? Or maybe it needs to grant access to Team3 plus someone special in Team2? We then need to use “Access Groups” to provide finer grained access control. First we define the group and it’s members:
Then we use the “Restricted Access” menu item on a Work Item to set visibility to the Access Group.
Now the “Task for access group 1” is visible to Bob (Team1), Curtis, and Marco (Team 3.2), but not to Dave, Deb or Al (look for the “Task for access group1” Work Item in the previous images showing the results of the All Work Items query).
Turning to Requirements 1-4 which are SCM requirements now. With the team area hierarchy as it is, we can define a number of components and by setting the Owner/visibility property
determine which Teams have access to it. So here’s a list of components with the team ownership shown. Assuming that the “Restrict to members of this team area and its child team areas” property is enabled, here is what each of the different team members sees when looking at a stream which is configured with all of the components created earlier.
As with work item visibility, what if we needed something more than what the default team hierarchy provides in terms of component access? For example, what if there are “special” components that should be accessible only to Team1 and Team3.2? It would be nice if components also used the access groups capability, but since they don’t we can simulate the same functionality using Team Areas. First we create an additional Team Area for each SCM access group and add users to each Team Area.
As before we change the Owner/Visibility property of the components to their respective “SCM Access Group” Team Areas. Now Bob and Marco have additional, exclusive access to the “SCMGroup1_system_wlan” component, while Bob and Curtis have additional, exclusive access to the “SCMGroup2_system_wlan” component.
There is one additional piece that must be in place before this SCM model is usable. Since the Stream in use is owned by the Project Area and only Al is a member of the Project Area, only Al will be able to deliver changes to any components in that stream. If Bob tries to deliver changes to the stream, he will run into permission problem, even if he has access to the component being changed. One way to fix this is to add each user as a member of the Project Area as well. But this is less than ideal especially with large numbers of users as we will need to potentially add each user to three locations: the Project Area, the Team Area and the SCM access group Team Area . So a better option is to give “Everyone” Deliver permission at the Project Area level.
So what I’ve shown here is just one way to implement a very specific set of access control/visibility requirements with RTC. Although the original question was raised in the context of Android platform development, it should be obvious that these concepts can be applied to other situations as well.
There are a number of excellent articles on Jazz.net which go into the details of RTC’s Work Item and SCM access control, covering many other requirements:
Rational Team Concert: Access Groups usage and Work Items visibility
Controlling access to source control in Rational Team Control
Using the Work Item Access Restriction feature in Rational Team Concert
Using read permissions to protect source code
Patterns for read protecting source code