Request Build permission: Team or ProjectArea?
Hi, I've a question about how RTC gives permission to Request a build.
I've a user which belongs to TeamArea but not to ProjectArea. In process configuration I find permission to Request Build under Team Configuration and give it to the role of my user. But, if I don't add my user to projectArea members too, he can't request any buid. Why? Do I have to connect user both to ProjectArea and TeamArea member always? |
6 answers
Jared Burns (4.5k●2●9)
| answered Aug 06 '09, 8:21 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
On Thu, 06 Aug 2009 09:10:49 -0400, Geoffrey Clemm wrote:
Roles are not inherited between process areas (either up or down). So Thanks, Geoff, but this is only half true. Role assignments *are* inherited from parent team and project areas. In fact, team areas inherit all process configuration from their parents - available roles, role assignments, permissions, behavior, timeline, etc. Process configuration in Jazz follows a sandbox model, where each team is free to configure it's process however it likes, but this configuration only affects that team and it's children - a team's configuration has no bearing on the process of its parent. There are good reasons that we work this way, but people sometimes get tripped up on this when they assign a role in a child team area and expect a parent to honor that assignment. Back to the question about the Build permissions, it's possible that this is what Michele is hitting. The project area says that anyone with RoleX can start a build and the user is assigned RoleX in a team area. But if the build that they're requesting is owned by the project area, then the Process runtime will ask the project (not the team) for the user's roles and the user doesn't have RoleX in the project area. If you open the build definition (right click in the Team Artifacts view and select Open Build Definition), you'll see a "Project or Team Area" field in the top left which tells you what team or project owns the build. Also, the "Why Did This Happen?" link in the Team Advisor should tell you what team or project area was used when you made the request. -- Jared Burns Jazz Process Team |
Geoffrey Clemm (30.1k●3●30●35)
| answered Aug 06 '09, 9:10 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Roles are not inherited between process areas (either up or down). So
having a role in a parent process area does not automatically give you that role in a child process area, and conversely, have a role in a child process area does not automatically give you that role in a parent process area. Cheers, Geoff mikyjpeg wrote: Hi, I've a question about how RTC gives permission to Request a |
I understand this, and this is why I have my user with his role but in TeamArea, because permission on Request build seems to be related to TeamArea and not to ProjectArea.
So why do I have to put my user into ProjectArea too if he has only to request builds? If my user must be also a project area member I was thinking that maybe this permission is on the wrong section of the configuration. |
Geoffrey Clemm (30.1k●3●30●35)
| answered Aug 06 '09, 5:34 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Thanks Jared ... two foul balls in two days ... maybe I'd better limit
my responses to SCM question (:-). The only excuse I can think of is that I was expecting the inherited membership to appear in the Member list to reflect that inheritance ... except right there above the Member list it states explicitly: "The roles assignments below are also valid in all child team areas." I guess "half right" is the best I can do with this one (:-). I will make a couple of enhancement requests though ... one to allow a team area to say "I don't want to inherit the role assignments of my parent" (since there are cases where you'd want to inherit the process customizations of a parent team area without inheriting its role assignments), and another to say that "inherited role assigments should appear in some form in the team area membership list". Cheers, Geoff Jared Burns wrote: On Thu, 06 Aug 2009 09:10:49 -0400, Geoffrey Clemm wrote: |
Geoffrey Clemm (30.1k●3●30●35)
| answered Aug 06 '09, 6:52 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
The terminology used here is known to be a bit confusing. The way I
think about it (which could easily be off the mark, given my recent blunders wrt process on this forum :-), is that the "project configuration" information cannot be modified in child team areas, while the "Team Configuration" contains information that can be modified/overridden in child team areas. So since the permissions can be modified/overridden in the child team areas, they appear in the "Team Configuration" section. Cheers, Geoff mikyjpeg wrote: I understand this, and this is why I have my user with his role but in |
Thank you very much for the answers, it makes sense for me now.
I've seen that my build definition is related to ProjectArea, so if I associate it to TeamArea this would run correctly. This association has impacts only on ownership of the definition (and so on permission) or could have other impacts (for example on change-set acceptation before run)? |
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.