In our upcoming release of Rational Team Concert (as part of our Collaborative Lifecycle Management solution planned for 2Q 2011), we are expanding the permissions available in source control.* Way back in RTC 2.0, we added support for SCM read permissions that centered on process areas. In this next release, we’re improving read access for artifacts owned by team areas, and we’re tightening up default permissions on newly created streams, repository workspaces, and components. You can check our progress by downloading and trying our latest milestones of Rational Team Concert.

Using team areas to control access

Project areas and team areas define the organizational chart of the development group, and they control read/write access to artifacts. Prior to the current release under development, making a team area the owner of a component or stream had the same effect as making the ancestor project area the owner. In both cases, the component or stream was visible to everyone in the access control list of the project area. Unfortunately, that made life difficult for projects where some source code is sensitive and shouldn’t be available to members of every team. The only way to individually control access to specific streams and components was to make them owned by different project areas. That causes a growth in the number of project areas and blurs the lines on the organizational chart.

In our next release, however, this is all changing. Team areas can now be used to limit read access with a finer granularity than project areas. When you set a component or stream as owned by a team area, you can mark it as private to that team area. Private artifacts are only visible to members of the team area and its descendants. This allows access control to follow the lines of the organizational chart and lessens the need to create project areas solely for permissions.

Let’s see how the new permission would be used in real life. Consider the following example: The JUnit team doesn’t want to maintain the core logic of their flux capacitor any more. So they’ve decided to rebuild it with source code licensed from YoyoDyne Inc. But the license agreement stipulates that only a handful of programmers may have access to the code. The JUnit project area has members that shouldn’t be allowed to see YoyoDyne’s source, but the work on the new flux capacitor should follow the same development process that the JUnit team uses.

Before we developed the new permissions, the JUnit project administrators would have had to create a new project area to host YoyoDyne’s source code, and make its components and streams visible only to that project area. With our next planned release, administrators can create a new team area within the existing JUnit project area, and mark the source control artifacts as private to that team area:

Sample process hierarchy

The JUnit Project Area contains the streams and components used by the regular JUnit development team. The team area called Flux Capacitor Tiger Team contains a component with YoyoDyne’s code (Flux Capacitor 2) and the stream it’s built out of (Flux Capacitor Rebuilds).

• Marlene is a member of the team area. She has access to the Flux Capacitor Rebuild stream and the Flux Capacitor 2 component, as well as the stream and component called JUnit.
• Jason is a member of the project area. He isn’t allowed access to YoyoDyne’s source. Since he’s a member of the project area, he can see the JUnit stream and component, but he isn’t a member of the Flux Capacitor Tiger Team, so he can’t see YoyoDyne’s code.
• Roy, an outsider, does not have access to the stream or component containing YoyoDyne’s code.

If there were another team within the Flux Capacitor Tiger Team, its members would have access to the Flux Capacitor Rebuild stream and the Flux Capacitor 2 component. Conversely, other team areas inside the JUnit Project Area would not be able to access artifacts owned by the Flux Capacitor Tiger Team.

To support the new workflow, we’ve made the following UI tweaks for the Eclipse client:

1. The Stream editor shows the visibility of the stream:
   

   The stream editor's new visibility field

   Users can control whether the stream is private to team areas by toggling between the project area and the team area in the drop down.

2. The Component Owner dialog now has a team private scope checkbox:
   

   The component owner dialog's new visibility field

   When the checkbox is ticked, the component will only be visible to members of the selected team area.

3. The Team Artifacts view has new decorators:
   

   Decorators for components in the Team Artifact Navigator

   Components owned by team areas are decorated with the green and blue pawns, while components owned by project areas are decorated with the blue file folder. The tool tip that appears after hovering over the decorator shows the visibility and owner of the component.

Default permissions for streams, repository workspaces, and components

Jazz is developed in an open manner. We encourage our users to look at our work items, and we make most of our source code available. So when we made the first cut at source control permissions, we opted for openness and made source control artifacts (streams, repository workspaces, and components) default to publicly accessible. But not all teams work the way we do, so we’ve changed the default access control to make these artifacts private on creation.

We don’t expect most users to notice the change. In our use, the only gotcha associated with the new default has been caused by running personal builds, since the build user loads a user’s repository workspace. To mitigate the pain of starting a build only to see it fail during the load phase, we’ve added a warning to the personal build dialog in the Eclipse UI.

To find out more about source control read access and process in Jazz, see:

• the post on source control read permissions in RTC 2.0
• the article on process in Jazz and RTC.

Evan Hughes
Jazz Source Control Developer

* Our lawyers would like me to remind you that these are not finalized plans or commitments, but just work in progress, and plans are subject to change without notice. See the Terms of Use.