Request Build permission: Team or ProjectArea?

On Thu, 06 Aug 2009 09:10:49 -0400, Geoffrey Clemm wrote:

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.

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

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
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?

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.

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:
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.

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.

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
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.

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)?