Team areas in the GCM application

Edit online

Use team areas for greater control over write access to components and configurations in a project area. By creating different team areas, you can grant specific privileges to specific users for specific artifact types. For example, you can use team areas to allow or prevent team members from editing particular configurations.

Typically, you can grant more permissions with team areas than with project areas. A team area inherits permissions from its parent team area or project area. Team areas have the same behavior in all IBM® Engineering Lifecycle Management applications. For details, see Team area.

Team areas don't affect setting the configuration context in the Current Configuration menu on the toolbar.

In the Global Configuration Management (GCM) application, an administrator can create a team area, add members, and assign the write (modify) access that the team needs for components, streams, and baselines. A configuration lead can then assign that team area to the items that the team area members must modify.
Note: A team area can be assigned to an item by anyone with permission to modify that item. In the following examples, a configuration lead completes this task.

Administrators and team areas

Creating a team area is a common task for all Engineering Lifecycle Management applications. For details, see Creating a team area.

You can add any user from the external user registry and the IBM Jazz® Team Server repository to a team area. Team area members do not have to be project area members, and after you add them to a team area, they are not automatically added to the project area. All users in the repository have the Everyone role whether they are a member or not.

Team area members who are not project area members might gain read access to all artifacts in a project area, depending on the read access that is set for the project area. See these settings on the Access Control page of the GCM application administration pages. For details, see Restricting read access to project areas or team areas. For stricter control, grant access only to users in the access list.

You cannot assign the Tag Manager role or tags permissions to team areas. These permissions apply only at the project area level.

Assigning several project area roles and permissions can complicate team areas. To simplify using team areas, consider granting more restrictive roles at the project area level. Then, define team areas to broaden the privileges for team members.

Example: Consider an example where you are a GCM application administrator and the administrator for the Electric Vehicle project area. Bob and his team work on a high-performance motor that your organization wants to test in a new version of an electric vehicle. However, Bob and his team are not members of the GCM Electric Vehicle project area.

A GCM configuration lead for the Electric Vehicle project area asks you to create a team area that assigns the Configuration Lead role to Bob and assigns the Contributor role to his team members. You create a team area named Tuning Team and assign the people and roles as requested. The configuration lead will assign this team area to the components and configurations that Bob and his team work on.

In GCM, Bob and his team do not automatically become members of the Electric Vehicle project area. They are only members of the GCM Tuning Team team area. They cannot complete any tasks on the Motor - Performance Beta 0.0 variant in GCM until the Tuning Team team area is assigned to that stream. However, depending on the project area access controls, they might be able to see the configurations and components in the project area. Consider reviewing the access controls and changing them if needed.

As an administrator, your task is now complete. A configuration lead can now assign the Tuning Team team area to the items that Bob and his team must access, as described in the Practitioners section.

After team areas are created and assigned, if team members cannot complete their tasks, such as choosing a configuration context or accessing the artifacts that they need, verify these items:
  • Check their permissions at the team area level and project area level.
  • Check the read access settings on the Access Control.

A team area can be assigned to an item by anyone with permission to modify that item. If not managed carefully, teams might be granted inappropriate access to items. Component organization is an important consideration. For details, see the Assigning a team area to a component section in this topic.

Practitioners and team areas
  • To define the team areas that you need, work with a GCM application or project area administrator.
  • To assign a team area to a component or configuration, you must have permission to modify that item.

    For example, to modify the Team Area attribute for a component, you must have permission to modify components.

  • Assign or remove a team area for a single component or configuration on the Attributes tab for that item. You can also select multiple configurations or components and select Edit Attributes.
  • Team areas cannot be assigned to local contributions in a GCM hierarchy. Consider an example where StreamA from the Requirements Management (RM) application is a contribution to the GCM GC1 stream. Your RM privileges apply to the StreamA contribution.
For details, see Customizing access to components and configurations by using team areas.

Team Area attribute values

You can select one of the following values for the Team Area attribute:
  • An existing team area.
  • Unassigned: The roles and permissions defined at the project area level apply. Select this value to remove a team area assignment.

    When you create a component, this is the default value for its Team Area attribute.

  • Inherit From Component (team_area): Available only for configurations.
    By default:
    • The initial stream and baseline inherit the value assigned to the component.
    • A new configuration is assigned the same team area as the configuration it's created from.

    Changes to the Team Area attribute of the component are automatically reflected in the configuration. In the configuration details, you see the Team Area attribute as Team_area (inherited).

    Example: When the administrator creates the Motor component of the electric vehicle, its Team Area attribute is set to Unassigned by default. Also, by default, the initial stream and baseline (which are created automatically) inherit the component's team area assignment, so the Team Area attribute is automatically set to Unassigned (inherited).

    As development continues, you create the Motor 1.0 and Motor - Performance Beta 0.0 streams from the initial baseline. These new streams are assigned the same team area as the configuration they're created from. In this example, no team area is assigned yet in the initial baseline, so the Team Area attribute for the new streams is also set to Unassigned (inherited). Later, you change the Team Area attribute for the Motor component to Tuning Team. In the Motor 1.0 and Motor - Performance Beta 0.0 streams (and all streams that inherit the value of the component), the Team Area attribute is automatically updated to Tuning Team (inherited).

    When you no longer need a configuration to inherit the team area from its component, set the configuration's Team Area attribute to Unassigned or to a different team area. Notice that Unassigned is not the same as Unassigned (inherited).

    In the example, if you change the Team Area attribute for the Motor component back to Unassigned, the team area attribute in the Motor 1.0 and Motor - Performance Beta 0.0 streams is automatically updated to Unassigned (inherited).

Example:

The GCM Electric Vehicle project area contains a variant named Electric Vehicle - Sport 2.0. This variant is assembled from configurations of different components that are developed by multiple teams. This variant uses the Motor 1.0 engine (a variant of the Motor component), as shown in the following image.
Shows the Electric Vehicle Sport 2.0 configuration hierarchy, which contains the Motor 1.0 stream

The organization wants to assess whether performance improvements to the engine are feasible in the Electric Vehicle - Sport 2.0 variant. The configuration lead creates the Motor - Performance Beta 0.0 stream from the initial baseline of the GCM Motor component and replaces the Motor 1.0 stream with the Motor - Performance Beta 0.0 stream.

To grant write access to Bob and his team (who are not project area members), the GCM configuration lead asks the GCM project area administrator to create a team area named Tuning Team. The GCM administrator assigns Bob the configuration lead role and gives Bob's team members the privileges they need.

For now, Bob and his team need access to only the Motor - Performance Beta 0.0 variant. The configuration lead assigns the Tuning Team team area to only that stream, as shown in the following image.
Highlights the Motor - Performance Beta 0.0 stream in the hierarchy, with the team area set to Tuning Team.

Bob and his team can now complete their tasks but only for this engine variant and the streams and baselines created from it. Depending on the read access controls for the project area (for details, see the Administrators section), they might be able see other configurations in the hierarchy, but they cannot modify them. The Tuning Team privileges don't apply to the other components or streams in the project area. Conversely, project area members who are not on the tuning team can't modify the Motor - Performance Beta 0.0 configuration or configurations derived from it.

As development progresses, new configurations of Motor - Performance Beta 0.0 derive the same team area, which enables Bob's team to work independently. Bob, as a configuration lead of the Tuning Team team area, can replace the Motor - Performance Beta 0.0 stream with other configurations created from that stream.

Considerations for assigning team areas to components

In the example, both the Motor 1.0 and Motor - Performance Beta 0.0 streams are variants of the Motor component.

It's important to manage team area assignments carefully. For example, if the configuration lead assigns the Tuning Team team area to the Motor component, Bob's team will have write access for any Motor variant that inherits the team area value from the component. This assignment could interfere with other teams' work or affect project security. When working with multiple teams or even multiple vendors, component organization is an important consideration. For details about these considerations, see CLM configuration management: Defining your component strategy on Jazz.net.