Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

restrict delivery to components in a stream

I'm trying to use the "restrict delivery to components in a stream" precondition to restrict who can deliver to a stream (a single role in the team that owns the stream). I thought it would be easier to configure this during lockdown phases of our projects than flipping permissions or setting up a separate team for locking purposes.

However, I found a user can deliver if they're in ANY parent process area (team or project) with this role. For example:

Team Org

Project P
--- Team T

Setup

Stream owned by team "T"

role "R" is allowed to deliver in project "P"
user "U" has role "R" in project "P"

In team "T" process customization, the "Deliver (server)" precondition set for "Everyone (default)" and configured to restrict deliver to role "R" of team "T"

Results

User "U" can deliver even though they're not a member of team "T".

Questions

Am I missing something?
Is there another way to easily lock a stream?

Appreciate any help

0 votes



2 answers

Permanent link
Yes, if you have a role in a parent project/team area, then you have
that role in all child team areas, unless you are explicitly given
different roles in those child team areas. Explicitly removing those
roles isn't a very scalable solution, since it means you have to
know/remember to remove those roles for anyone new added to the parent
project/team area.

What you probably want is work item 89455 "Allow turning off role
assignment inheritance from a team area". If so, you might want to add
a comment to that work item indicating your interest/support.

Until that work item is implemented, the best approach is to not give
that role to any members of the parent team areas (which might mean
creating a new leaf team area, for the work currently being done in the
parent team area).

Cheers,
Geoff

On 8/31/2011 7:08 PM, eanderso wrote:
I'm trying to use the "restrict delivery to components in a
stream" precondition to restrict who can deliver to a stream (a
single role in the team that owns the stream). I thought it would be
easier to configure this during lockdown phases of our projects than
flipping permissions or setting up a separate team for locking
purposes.

However, I found a user can deliver if they're in ANY parent process
area (team or project) with this role. For example:

Team Org

Project P
--- Team T

Setup

Stream owned by team "T"

role "R" is allowed to deliver in project "P"
user "U" has role "R" in project "P"

In team "T" process customization, the "Deliver
(server)" precondition set for "Everyone (default)"
and configured to restrict deliver to role "R" of team
"T"

Results

User "U" can deliver even though they're not a member of
team "T".

Questions

Am I missing something?
Is there another way to easily lock a stream?

Appreciate any help

0 votes


Permanent link
Geoff, two follow up questions on this:
1. If you have a role only in the child team area, then you have implicit access to the parent project area with the default/everyone role. Is that correct?
2. If you have a role in a parent project, how do you inherit that same role in the child team areas? Is it by default or only if you add as a member to the team area with no role defined? I ask because I thought we ran into problems with users not being able to do certain things without explicitly add to child teams (i.e. view team dashboards or queries or problems with streams or creating work items).

Yes, if you have a role in a parent project/team area, then you have
that role in all child team areas, unless you are explicitly given
different roles in those child team areas. Explicitly removing those
roles isn't a very scalable solution, since it means you have to
know/remember to remove those roles for anyone new added to the parent
project/team area.

What you probably want is work item 89455 "Allow turning off role
assignment inheritance from a team area". If so, you might want to add
a comment to that work item indicating your interest/support.

Until that work item is implemented, the best approach is to not give
that role to any members of the parent team areas (which might mean
creating a new leaf team area, for the work currently being done in the
parent team area).

Cheers,
Geoff

0 votes

Your answer

Register or log in to post 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.

Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details

Question asked: Aug 31 '11, 1:36 p.m.

Question was seen: 3,649 times

Last updated: Aug 31 '11, 1:36 p.m.

Confirmation Cancel Confirm