Rational Team Concert: Access Groups usage and Work Items visibility
This article describes the basics of the new Access Groups feature available from Rational Team Concert 4.0. This feature provides a new way of restricting the read permissions of a work item based on group of users. The Access Groups capability provides a flexible way of grouping users that can expand beyond the team organization structures for the development effort defined by project areas and team areas.
Introduction
The concept around work items aims for collaboration and transparency in development. Work items are not just the tooling for keeping track and organizing your work (and your teams’), but they also provide the means of keeping your team collaborative with the flow of information that will speed up the resolution of tasks, fixing of bugs and transparency that will help enhance your process and your product in an ALM environment.
However, there are use cases where the access to the information contained in the work items needs to be restricted to certain group of users, within the team development effort context contained in a project area. Rational Team Concert has been incorporating features to provide support to that range of use cases that need to restrict access to work items, such as: private feature discussions, high-level information meant just for lead roles, private team work information or, work with software providers where some information is considered sensitive or confidential.
RTC version 3.0 introduced the Work Item Access Restriction feature. In that particular version, a Work Item’s read access could be restricted to the members of a different project area. RTC version 3.0.1 extended that feature by providing the ability to specify the read access restriction to the members of a certain team by means of the Filed Against field and the associated Work Item Category. Now version 4.0 adds a new feature called Access Groups that we will introduce in this article.
Access Groups
The main defining characteristics of this new feature in contrast with the capabilities from previous versions are:
- It provides the concept of aggregated security contexts. What does this mean? Well, it provides the ability to define these groups as an aggregation of project area(s), team area(s) and/or individual users. That set of contexts will be considered for determining the read access to the work item.
- Access groups provide a common definition of a set of users. They can be used in different project areas, but they are just a grouping definition not tied to a process structure.
In the rest of the article we will use the Money That Matters sample and the fictitious banking company, JKE Banking to illustrate some of the activities.
Defining Access Groups
The feature is available for the project administrators (users with JazzProjectAdmins role) of the CCM application, accessing your server at https://<public URI>:<port>/ccm/admin
From that point we can click on Create Access Group, which will open the window for defining a brand new group:
The window that pops up allows you to create a new group whose user list can be composed of project areas, team areas and/or individual users. We can, for example, create a special group for discussing and reviewing special feature requests for one of our teams, including roles and users who are not directly related with the day by day work. For that reason, they don’t need to be part of any particular project area or team area:
How Access Groups work
Now that we have one access group created, we will see it in action. The JKE Banking sample Project Area defines “Everyone” for the project area Access Control, thus anybody with access to the repository can read the project area work items. Running the predefined query for “Open Stories” will give us the following result:
To use this new feature you can add the presentation to the Restricted Access field in the Story Work Items, allowing you to modify the access from any client, including the web one:
From that point, we are able to restrict the visibility of Story type work items. That access can be limited to a certain project area, or to an access group composed of a combination of contexts at your will. For example, a team area and a couple of users:
All the work items specifying that restricted access group won’t be accessible to users outside of it (unless users with JazzAdmins roles, of course!).
General Tips
There are a few things to consider when working with access groups which have a lot in common with the features for read control:
- An Access Group definition does not overwrite the access defined for the Project Area. If a user doesn’t have read access to a certain project area, they won’t be able to access its work items, even if a work item within that project area is configured to restrict visibility to a group the user is member of.
- A user will have to be member of an access group to be able to use it to restrict visibility (or even see it listed). Note that a user with JazzAdmins role will always see the defined access groups.
- Even when using access groups a user with the JazzAdmins role will be able to see the work item information. Users with just JazzProjectAdmins role, or regular users defined as administrators of the project area where the work item resides won’t.
We have already reviewed the basics of how to use the access group feature, how to enable its presentation, and general tips to consider when restricting access to information. In the rest of the article we will review some collateral information around this feature and what we had available from previous versions of Rational Team Concert.
Access Groups and other visibility control features
Now that we have seen how to use this new feature, an obvious question arises: What is this feature adding to what we already had? So let’s have a quick peek at a comparison with the other mechanisms available: (check the References section of this article for further information of the features here discussed)
Restrict visibility based on membership to another project area: it works basically the same way as using access groups. We can consider access groups as a generalization (and improvement) of this mechanism. With this new feature, why would you need to use a secondary project area for access restriction? Well, there can be cases where either of them can better match your needs. As a rule of thumb: if you need to restrict access to certain users (or a combination of teams and users) use access groups. If the access to work items is to be restricted to just users of a certain project area which has its own process, artifacts, etc. you can still use it that way and, in the meantime, ask yourself if the work item shouldn’t be moved to that project area.
Restrict visibility based on categories (team area assignment): if the teams working in the development effort within your project area need to have some private discussion, it is likely that this feature will better fulfill your needs. You may need to take into acccount the following considerations however:
- Note that the visibility based on category was initially meant for root-level team areas. In a hierarchy of team areas, the visibility heritage then works in a bottom-up manner (see References).
- The different types of access restriction features are not meant to be used in combination. If you really need to restrict access to some work items, choose the one that better fits your needs.
Impact of Visibility Restriction
At this point, we have reviewed how access groups work and the main differences when compared with other features for restricting visibility. But Rational Team Concert is not just about work items, so it is worth to check what will be the behavior when put in a broader context:
- Navigation from other artifacts: like checking the work item associated to a change set, or a work item reported against a build. Restricting access to work items used in that contexts can break traceability navigation for other users.
- ALM traceability: linked work items will still show up as linked elements to related artifacts for requirements or quality management, but navigation to it will be restricted.
For more information
- Control Access to project areas and their artifacts
- Using the Work Item Access Restriction feature in Rational Team Concert
- Enhancement: Parent team areas should see private work items in children
About the author
Jorge A. Diaz is a member of the Jazz Jumpstart Team. The Jazz Jumpstart Team is a worldwide group of development specialists who bring new and advanced Jazz-based technologies to customers. For additional information about the topic presented in the article add your comments or questions directly in the discussion part, or visit our Jazz.net Forum.
© Copyright 2012 IBM Corporation