Do SubTeams inherit members from their parents?
If team T has members a, b, and c, and I define a subteam of T with member d, does that subteam also have as members, the members of it's parent team?
|
3 answers
On 3/14/12 10:57 , marshallschor wrote:
If team T has members a, b, and c, and I define a subteam of T with No, members of a parent team are not automatically members of a subteam. But there are cases where RTC behaves as if they were. When checking permissions to see whether or not a user is allowed to perform an operation, any roles that a user has in a parent team area are used when looking up the permissions in subteams. For example, if T is a team area with U as a subteam, and user A is a member of team T with the role Team Member but is not listed as a member of team U, and user A performs an operation in the context of team U, then RTC will look at the permissions for role Team Member within team U to see if the operation is allowed (even though user A is not an explicit member of team U). If permissions are not explicitly specified in team U, then RTC will look at the role Team Member in team T, and so on up the chain all the way to the project area. So when checking permissions, RTC essentially behaves as if members of a parent team area were also members of subteams. But this inheritance of members does not apply to other areas of RTC. For example: If you create a work item category and associate it with team U and mark it so that only team members can file work items against that category, then a user must be explicitly listed as a member of that team area in order to use that work item category. Being a member of the parent team T isn't good enough. -- David Olsen | IBM Rational | Jazz Process Team |
On 3/14/12 10:57 , marshallschor wrote: If team T has members a, b, and c, and I define a subteam of T with No, members of a parent team are not automatically members of a subteam. But there are cases where RTC behaves as if they were. When checking permissions to see whether or not a user is allowed to perform an operation, any roles that a user has in a parent team area are used when looking up the permissions in subteams. For example, if T is a team area with U as a subteam, and user A is a member of team T with the role Team Member but is not listed as a member of team U, and user A performs an operation in the context of team U, then RTC will look at the permissions for role Team Member within team U to see if the operation is allowed (even though user A is not an explicit member of team U). If permissions are not explicitly specified in team U, then RTC will look at the role Team Member in team T, and so on up the chain all the way to the project area. So when checking permissions, RTC essentially behaves as if members of a parent team area were also members of subteams. But this inheritance of members does not apply to other areas of RTC. For example: If you create a work item category and associate it with team U and mark it so that only team members can file work items against that category, then a user must be explicitly listed as a member of that team area in order to use that work item category. Being a member of the parent team T isn't good enough. -- David Olsen | IBM Rational | Jazz Process Team Thank you. Can you please clarify this other case. In 3.0.1, there's a new checkbox when you re-assign a component's owner to a team, that says "Restrict to members of this team and its child teams". Can you confirm that this modifies the rule you stated above, so that the fact that a person exists in a higher level parent team with roles that permit things, doesn't apply when this check box is ticked. |
In 3.0.1, there's a new checkbox when you re-assign a component's (I'm not completely sure, since I have never used that particular feature before. But here is what I think the answer is.) That check box controls visibility, or read access. That is a completely different mechanism from roles and permissions, which govern write access. Read access is controlled by team membership, not by the roles assigned to a user. If read access is restricted to a particular team area, then you have to be a member of that team area (or one of its subteams). Being a member of a parent team area isn't good enough. -- David Olsen | IBM Rational | Jazz Process Team |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.