It's all about the answers!

Ask a question

Access Rights Lookup for Project Areas

Richard Good (872860) | asked Mar 09 '17, 1:33 p.m.

I seem to be getting conflicting advice from the help files and article

I have added a user to the Developer Role at Project level (formal change control process model) but not added them to any team areas. I have a stream owned by a Team Area and the visibility is locked to the team area. The process lookup article and help file seem to indicate that because I have added my user to the Project Area with a developer role that they should be able to see and deliver to the stream even though they are not explicitly in the relevant team. They cannot see or deliver to the stream.

Is the behaviour I am seeing correct? If so the help file is at best confusing and at worst incorrect.

If I add them to the team as well as the project area they can do what they want, but this is administratively onerous. We want a sort of super group of developers added to the project area and a bunch more added to the relevant lower level teams. So  cannot do what would seem obvious and set the visibility to the project area.

Thanks for any help



One answer

permanent link
Donald Nong (14.5k614) | answered Mar 09 '17, 7:33 p.m.

I think you linked the wrong article in your post, as it is about "behavior lookup", not "permission lookup". It should have been this one, which talks about the same thing as the Knowledge Center document.

For source code access control, I suggest you have a read of this article.

What you have done is exactly described in the section "Use permissions to control access to streams".

Richard Good commented Mar 10 '17, 5:18 a.m. | edited Mar 10 '17, 5:20 a.m.

Thanks for your time. It is hard for me to see that 292 is the wrong article. It describes exactly the operation the user wants to be allowed to do. i.e deliver a change set to a stream. Not sure why it is a good idea to view permissions to write to a stream and the operation of delivering to a stream as two different entities, The user/ me can hardly avoid getting confused. When busy, I prefer to read help files/ articles rather than exhaustively testing various scenarios. The help file seemed unambiguous and clear in giving me the wrong answer ;-) I think these articles and the help file need some remedial work especially the permissions one.

Here's a quote from the RTC help file

"A user who is assigned to a role in a project area has the permissions associated with that role in the project area and in its child team areas, even if the user is not a member of those child areas. For example, a user who has the Team Member role for a project area has the permissions associated with the Team Member role in all child team areas of that project area. "

Ralph Schoon commented Mar 10 '17, 5:32 a.m.

The difference between behavior lookup 

and permission lookup is dramatic.

  1. Permissions allow you to do something
  2. Behavior prevent operations even if you have permission to enforce rules
  3. Permission aggregates across roles in a context
  4. Behavior only executes for the first role found
There are some conceptual confusions in your question "I have added a user to the Developer Role" should rather read I assigned the user the Developer role

Ralph Schoon commented Mar 10 '17, 5:35 a.m. | edited Mar 10 '17, 5:36 a.m.

 The next issue here is that permission or operational behavior and visibility are completely different things. If the user can not see a stream, because the visibility is limited to the team area, all permissions does not help them to do anything. 

Yes, because of how permission lookup works, if you have a role on project area level, you inherit the permissions of that role for that context, but if you are not a team member you can not see items that are visible only to team members.

Your answer

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