Team Hierarchies

Cradle projects can group users into teams. A team can own information. Users who are in a team have read-only (RO) access to each others’ information (can be made read-write, RW) and can be given RO access to information owned by the team. A user is in only one team.

Projects can have a hierarchy of teams in a team hierarchy, a project-specific hierarchy of the names of the project’s teams. The team hierarchy allows a project to contain an arbitrary number of levels of team, and therefore an arbitrary number of levels of user.

The team hierarchy is defined in Project Setup tools. PROJECT privilege is needed:

We define the terms:

• A sub-team of a team A is a team that is a child, or grandchild, or great-grandchild (and so on) of A in the team hierarchy. That is, a sub-team of a team A is a team that is in the sub-tree below A in the team hierarchy.
• A super-team of a team A is a team that is a parent, grandparent, or great-grandparent (and so on) of A in the team hierarchy. That is, a super-team of a team A is a team that contains team A in the sub-tree below it in the team hierarchy.

This hierarchy of users and teams extends the project’s access control. Creating a hierarchy of teams creates a hierarchical access control mechanism for the project’s database. Two new user privileges have been added to support the team hierarchy, and the meaning of the existing TEAM_BYPASS privilege has changed. The access control rules are now:

• A user has RW access to information that he/she owns
• A user has RO access to information owned by users in his/her team, or RW access information if he/she has TEAM_USER_RW privilege
• A user with TEAM_RO privilege has RO access to information owned by his/her team
• A user with TEAM_LEADER privilege has RW access to information owned by his/her team and RW access to information owned by the users in his/her team
• A user with TEAM_BYPASS privilege has RO access to information owned by other teams that are siblings of his/her team (other teams whose super-team is the same as his/her team’s super-team)
• A user with the new TEAM_DOWN_RO privilege has RO access to information owned by teams that are sub-teams of his/her team (but not to information owned by users in such teams)
• A user with the new TEAM_UP_RO privilege has RO access to information owned by teams that are super-teams of his/her team, but not to information owned by users in such teams. This does not give access to information owned by the project.
• A user with PROJECT_RO privilege has RO access to information owned by the project that is in the latest closed baseline, but not information that is superseded or retired (typically in previous baselines) nor to information in an open baseline
• A user with BASELINE_RO privilege has RO access to information that is superseded or retired (typically in previous baselines) and to information in an open baseline
• A user with BASELINE_RW privilege has RW access to information in any baseline. Any use of this privilege is recorded in the project’s Configuration Log.

The Configuration Management System (CMS) now supports team hierarchies. Each CMS review moves items up one level in the hierarchy. For reviews in teams not at the bottom of the team hierarchy, a user with TEAM_REASSIGN privilege can direct items that pass a review to be owned by teams that are sub-teams of the user’s team, or members of these teams, or members of the user’s own team.