Restricting Access to a Stream

Hi Guys,

Ok, I think I have this working - at least workable. I'll explain my setup and the bits that didn't work as expected.

New Scenario:

2 Teams, A and B
2 components, also A and B
2 Users, 1 and 2, both Developer Role (This was done on new project using the Formal Process)
1 Stream

Team A contains both users
Team B contains just User 2

Team A owns the stream

Both the components are owned by the project and are in the stream.

I then customise the process of Team A, adding an 'Operational Behaviour' on 'Deliver (server)' for Everyone
Add the 'Restrict Change set delivery to components in a stream' precondition.
Configure the conditon: select the stream, then select Component B and Click Edit Permissions, under Role Assignments, select Team B and then check 'Developer' in the bottom window. Save all and test...

At this point, if I've got all my A's and B's the right way round, User 2 should be able to deliver to both components whereas User 1 should only be able to deliver to Component A.

Things that didn't work -
in the 'Edit Permissions' dialogue in the precondition, there's a 'Give access to the owner of the component' option. I couldn't get this to work. The main problem I had with this was that there's no way to view the ownership of a component, the only way to check it is to set it again.
Anyway I tried to set the owner ship of the components to each stream and tried to use this flag and it didn't work - it seemed to deny permission all the time.

The other curiosity was this - when you go in to select who has access, you get a list of roles that you can check to say that they have access. There's a 'default' one that I took to mean 'regardless of role' so I checked default the first time around and it didn't work. I now believe that this default value is for members of the team that have no process roles.

HTH,

Robin

Great feature, great thread, thanks all!

But, if I create a new component and propagate it from my wide-open Dev stream to my progressively more restricted QA and Prod streams, I have to remember to add restrictions for these new components in each stream, right?

If that's right, it'd sure be handy to have a stream-level "default" restriction that gets applied to new components in this type of stream structure. That would avoid the need for a manual process step in a preventative control like this.

I'd be happy to create a WI for that - just say the word....

(I'd be happier still if there's some handy way to do this already that I'm ignorant of...)

- Larry

Great feature, great thread, thanks all!

But, if I create a new component and propagate it from my wide-open Dev stream to my progressively more restricted QA and Prod streams, I have to remember to add restrictions for these new components in each stream, right?

If that's right, it'd sure be handy to have a stream-level "default" restriction that gets applied to new components in this type of stream structure. That would avoid the need for a manual process step in a preventative control like this.

I'd be happy to create a WI for that - just say the word....

(I'd be happier still if there's some handy way to do this already that I'm ignorant of...)

- Larry

If the stream has visibility restrictions, the components in the stream won't be seen. A user can't deliver to a stream he can't see. Is that the kind of restriction you want?

Hi Tim, thanks for the response. Let me give some quick background on the client.

This particular client is on an RTC adoption "journey". For their first implementation, their organization is not really Team-Area friendly (everybody works on everything), and the bulk of their source artifacts aren't (yet) Component-friendly. To get them some SCM functionality quickly, it's one Project Area, no Team Areas, and one gigantic (7,800 source artifacts) Component. As they can, they'll analyze the Big Component and cut it up into more reasonably-sized Components. As they do that, a Team structure will naturally fall out, probably.

Without Teams, 2.0-style access restrictions could work, but they're based on user ID access lists, while the Permissions are Role-based, making for a messy process that seems error-prone. Or, you could add people with the permitted Roles to a team, but that's more double-maintenance. 3.0.1-style restrictions look to be team-based (plus, they aren't here yet), so they won't work for this client at the moment, unless we put the Contributors with the Roles on their own "Role-based Teams".

Any of those approaches would work, but the processes seem a bit complicated in this client's current environment. As they an their RTC implementation mature, the access controls based on team ownership of streams and components will be the right solution.

In the meantime, It's probably OK just to remember to restrict new Components as they're added to restricted streams.

- Larry

Just wanted to mention that I noticed (and missed it, if it's documented) that you need to create one instance of the restriction precondition for each stream.

- Larry.

I am trying to implement something similar to this.

I have Two teams (A, B ) , Two Components and one stream.

I want to enforce such that team A should deliver to CompA and team B to CompB. while the stream should be owned by the project as few member at project area level should have access to both the components.

I have set steam owned by to Project. CompA is owned by TeamA and CompB is owned by TeamB. but this does not work as expected.

I have already posted question for this https://jazz.net/forum/questions/224030/configuring-team-areas-at-component-level-in-rtc

Please help me on this.