Team Area Permission / Delivering Change Set
Hi,
i have the following Team structure:
Project Area A
-Team 1
---Team 1.1
---Team 1.2
-----Team 1.2.1
UserA who is member of Team 1.2.1 wants to deliver to Stream A, that is owned by Team 1.
UserA is granted the permission "Source Control => Deliver (Server) => Modify => Stream => Deliver => Deliver Change Sets" which is controled by RoleA.
However UserA cannot deliver a changeset to Stream A (Problem: You don't have permission to Deliver .), but when StreamA is owned byTeam 1.2.1, he can deliver the changeset.
Do the team members always have to be member of the teamarea which
governs the operation?
So, do the members of team 1.1, 1.2 and so on have to be members of team 1, too (redundant), to deliver to Stream A that is owned by Team 1??
Thanks in advance,
Thomas
i have the following Team structure:
Project Area A
-Team 1
---Team 1.1
---Team 1.2
-----Team 1.2.1
UserA who is member of Team 1.2.1 wants to deliver to Stream A, that is owned by Team 1.
UserA is granted the permission "Source Control => Deliver (Server) => Modify => Stream => Deliver => Deliver Change Sets" which is controled by RoleA.
However UserA cannot deliver a changeset to Stream A (Problem: You don't have permission to Deliver .), but when StreamA is owned byTeam 1.2.1, he can deliver the changeset.
Do the team members always have to be member of the teamarea which
governs the operation?
So, do the members of team 1.1, 1.2 and so on have to be members of team 1, too (redundant), to deliver to Stream A that is owned by Team 1??
Thanks in advance,
Thomas
4 answers
> So, do the members of team 1.1, 1.2 and so on have to be members of
> team 1, too (redundant), to deliver to Stream A that is owned by Team 1??
Correct. Permissions in RTC aren't inherited, thus being on a sub-team doesn't grant you all permissions on items owned by a parent team.
Jean-Michel
> team 1, too (redundant), to deliver to Stream A that is owned by Team 1??
Correct. Permissions in RTC aren't inherited, thus being on a sub-team doesn't grant you all permissions on items owned by a parent team.
Jean-Michel
On Thu, 30 Apr 2009 13:38:02 +0000, jlemieux wrote:
I think you meant the right thing, Jean-Michel, but it came out
backwards. ;)
The permissions that a team area grants to a role are inherited by child
team areas down the hierarchy. In the example here, RoleA is granted
permissions in Team 1, so those permissions apply to everyone who is
assigned RoleA in Team 1, Team 1.1, and Team 1.2.1.
Likewise, role assignments in a team area are inherited by child team
areas down the hierarchy. In the example here, if you are granted RoleA
in Team 1, you would also play RoleA in Team 1.1 and Team 1.2.1.
In this specific situation, though, you are only assigned RoleA in Team
1.2.1. This does *not* give you RoleA in any parent team areas, so when
you try to deliver to Team 1 you do not gain RoleA's permissions.
--
Jared Burns
Jazz Process Team
So, do the members of team 1.1, 1.2 and so on have to be members
of
team 1, too (redundant), to deliver to Stream A that is owned by
Team 1??
Correct. Permissions in RTC aren't inherited, thus being on a sub-team
doesn't grant you all permissions on items owned by a parent team.
Jean-Michel
I think you meant the right thing, Jean-Michel, but it came out
backwards. ;)
The permissions that a team area grants to a role are inherited by child
team areas down the hierarchy. In the example here, RoleA is granted
permissions in Team 1, so those permissions apply to everyone who is
assigned RoleA in Team 1, Team 1.1, and Team 1.2.1.
Likewise, role assignments in a team area are inherited by child team
areas down the hierarchy. In the example here, if you are granted RoleA
in Team 1, you would also play RoleA in Team 1.1 and Team 1.2.1.
In this specific situation, though, you are only assigned RoleA in Team
1.2.1. This does *not* give you RoleA in any parent team areas, so when
you try to deliver to Team 1 you do not gain RoleA's permissions.
--
Jared Burns
Jazz Process Team
This gets me all the time. Jared, you are right but what confuses many people is exactly why it came out backwards ;)
Permissions are inherited, but having a permission in a sub-team doesn't give you permission on items owned by a parent team unless you are actually on that parent team with the correct role.
Permissions are inherited, but since permission checks start at the level that "owns" the items, in this case the stream, you have to be a member of the team that owns the items.
Jared has a good article on this, how both permissions and behavior lookups work in practice.
https://jazz.net/learn/LearnItem.jsp?href=content/docs/process-behavior-lookup/index.html
Cheers,
Jean-Michel
Permissions are inherited, but having a permission in a sub-team doesn't give you permission on items owned by a parent team unless you are actually on that parent team with the correct role.
Permissions are inherited, but since permission checks start at the level that "owns" the items, in this case the stream, you have to be a member of the team that owns the items.
Jared has a good article on this, how both permissions and behavior lookups work in practice.
https://jazz.net/learn/LearnItem.jsp?href=content/docs/process-behavior-lookup/index.html
Cheers,
Jean-Michel