Security issue: Need an ownership/visiblity recipe that allows single team ownership and multi-team visibility
![]() I am looking for a security/visibility recipe that will work for the use case described below. In our Project we have Components: A B C D E Teams: W X Y Z Ownership and visibility should be as follows: Component A: owned by Team W, visible only to Teams W, X and Y Component B: owned by team X, visible only to Teams W, X and Y Component C: owned by team Y, visible only to Team Y Component D: owned by team Y or (Y and Z), visible only to Teams Y and Z Component E: owned by team Y, visible to Teams W, X, Y and Z I can easily satisfy the requrements for C and D:
For E, it might be acceptable to have it owned by Y with project-scoped visibility. I am awaiting an OK from the team that owns it. If not, then the requirement for E will change to "Component E: owned by Team Y, visible only to Teams W, X, Y, and Z" I have not been able to come up with an ownership/visibility recipe that works for Components A and B. Any help I can get would be apreciated. Thanks, Alexa
|
Accepted answer
![]()
Geoffrey Clemm (30.1k●3●30●35)
| answered Aug 01 '13, 2:45 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Currently, RTC only provides "hiearchical" team-area based read-access control on components. In particular, you can say "only this team area and all of its child team areas have read access to this component". But this does not give you the flexibility you would need to achieve the permissions in your example. You could get most of them though. For example, by making Z the parent of W, and W the parent of X and Y, you can get the permissions you want for A, B, C, and E, but not the permissions you want for D. The only workaround currently to achieving this kind of precise access control would be to define a separate "component access control" team area for each different read-access control list, and explicitly add as members of a team area the users that should have access to that component. This would mean that every time you added someone to a team, you would need to add them as a team member of each of the appropriate component access control team areas. What we really want is work item Provide Access Groups in SCM (as already available for Work Item Access configuration) (249674) to be implemented. Alexa Nafke selected this answer as the correct answer
Comments Yes, we need more granular control over component visibility that is distinct and separate from component ownership.l
![]() FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
I understand (and agree with) the need to have more granular control over component visibility. Could you explain why this is distinct/separate from component ownership? The visibility, or read-access, to an RTC artifact is determined by its owner ... or stated otherwise, what would you use component ownership for, other than to determine access control for the component?
|
2 other answers
![]()
There is an existing enhancement which looks like it may add additional functionality to components and their permissions. I would suggest subscribing and adding any suggestions if needed:
Make it easier to set the permissions on the component root (192716) Comments ![]() FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
I don't believe Make it easier to set the permissions on the component root (192716) is relevant here. It is just a mechanism for defining access control on the root folder of the component, not for defining access control on the component as a whole. I believe the relevant work item is Provide Access Groups in SCM (as already available for Work Item Access configuration) (249674) (or one of its related work items). |
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.
Comments
When you say a "a component is owned by a team", what permissions did you intend that to imply. Write permission?
I am concerned here with read access. We have highly sensitive IP that needs limited visibility (component C in my use case). That was easy to set up. However, we have slightly less sensitive IP data that needs to be visible to multiple teams but must not be visible to all teams (Components A and B in my use case must not be visible to Team Z). That is more, everyone-except-Team-Z visibility. I have considered putting the multi-teams into a parent team that would own the component but I'm not sure that the individual teams will be OK having their components owned by everyone in the super-team. Also, what are the implications of team ownership for components with regard to tailoring processes?