Blogs about Jazz

Blogs > Jazz Team Blog >

Patterns for read-protecting source code

Rational Team Concert 2.0 includes project level read permissions, which allow for read-protecting artifacts in a project area. Read access control applies to all artifacts in the project and all its sub-teams. The simplest usage of this feature is to mark a project as read-protected and then carefully control the membership of this new protected project. Users not on the project will never know it existed. Here is an example of the Access Control page for a project area:

However, in practice we know that many teams would like to have a hybrid environment where only certain artifacts are hidden, but not all of them. Internally we have projects that must self-host in this way. They want to encourage community participation within our internal product teams, but cannot make the source code available to everyone in the repository. The good news is that this is possible in Team Concert 2.0. But, if you have an existing project or projects, there are some manual steps required to reconfigure projects and artifacts.

Here is a checklist of steps to consider when configuring from an open project (eg, no read access control) to using read access controls:

Scenario1: Read protect an entire project

This is the simplest model; you protect all the contents of a project area and only users that are members of the project can read the artifacts. For outsiders, the project just doesn’t exist. It won’t appear in the UI, and any queries performed on the repository will not contain artifacts from this project area.

Steps:

  • Open the Project Area editor and change to the Access Control tab to enable read permissions. (As shown in the first screenshot above)
  • Ensure that all components to be read protected are owned by a project area or a team area of the project being protected. This will protect the source files in that component no matter which stream or repository workspace contains an instance of that component. Component owners are shown in the Stream editors and in the Team Artifacts Navigator and their owners as well. When a component is owned by a user, it has an orange icon overlay as shown below. Use the Change Owner action to assign the component to the project area.

You can also search for all components in the repository and verify that ownership assignments are as expected using the Search > Jazz Source Control > Components… action.

Scenario 2: Read protect only source and builds

In this model you move all the source code to a private project and keep the work items in an open project. This is typical when you want to have some transparency in your project but don’t want to make the source code available.

Steps:

  1. First, create a new project area and configure its access control as in Option 1.
  2. Change the owner of the components that should be protected to the new project area.
  3. Change the owner of the streams that should be protected to the new project area.
  4. At this point you have a decision to make: Do you want to allow work items in the read only project area that would be only visible to the small set of users on that project, or should all work items be visible from the public project? If you want all work items to only appear in the public project, you can block the creation of private work items by removing the permission from every role to create work items in this project area as shown in the Permissions page of the project area editor.

  5. Developers can easily work by associating change sets to work items in other project areas. Having the code split between projects doesn’t affect linking of change sets. However, as expected, any users not on the new private project won’t be able to browse the change sets.

Scenario 3: Mixing read protected and public source in a stream

This is a hybrid of scenario 2 where you want to work on code within the same stream which is visible to some but not all.

Steps:

  1. Move some components to a read protected project, but keep streams and other components public. As long as a set of users are on both teams, it shouldn’t affect developers that can’t see some of the source.
  2. Use the same steps as in scenario 2, but keep a stream in the public project and add components from both the private and public project. This will allow a stream to have both read protected source and non-read protected source. For example, to protect sensitive code from some, but allow a common configuration of the product be built together and tracked together in a stream.
  3. Work item links to change sets that are private are protected from read permissions as well.

Video

If all of this was a bit much, here is a video to help understand how to use Team Concert 2.0 to implement these 3 scenarios. The demo uses a slightly modified JUnit example project as a starting point.

(Hint: The video was recorded in HD and is best viewed in full screen mode. After clicking to play, click the second button on the bottom right of the player bar. For lower bandwidths, play in normal quality.)

Jean-Michel Lemieux
Team Concert PMC
Jazz Source Control Lead