It's all about the answers!

Ask a question

Restricting Access to a Stream


Alan D (15631311) | asked Jul 20 '10, 11:54 a.m.
edited Jun 30 '16, 12:00 p.m. by David Lafreniere (4.8k7)
I have 4 streams in a project area: DEV, TST, STG and PRD.

I'm happy for developers to check in and deliver all sorts to DEV, but the current set up of RTC doesn't seem to allow me to prevent the developers promoting change sets from Dev to Tst to Stg to Prd.

Can I tie down certain Streams so that only users with an appropriate role can promote/demote change sets between these restricted Streams.

This is a requirement from an Audit viewpoint.

Thanks.

16 answers



permanent link
Deepali Deshmukh (8913759) | answered Jun 30 '16, 2:50 a.m.

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.


permanent link
Larry McCarthy (2102224) | answered Jun 03 '11, 12:51 p.m.
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.

permanent link
Larry McCarthy (2102224) | answered Jun 03 '11, 12:46 p.m.
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

permanent link
Tim Mok (6.6k38) | answered Jun 03 '11, 9:31 a.m.
JAZZ DEVELOPER
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?

permanent link
Larry McCarthy (2102224) | answered Jun 02 '11, 2:08 p.m.
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

permanent link
Robin Parker (32633738) | answered Mar 29 '11, 6:20 a.m.
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

permanent link
Tim Mok (6.6k38) | answered Mar 28 '11, 10:33 a.m.
JAZZ DEVELOPER
Hi Robin

I found that adding / removing users from the Team Areas had very little impact, unless one removed all users from each Team Area, and also removed all users from the Project Area as well (this last step appeared to be the key). Once the permissions were set up at both the Project and Team Area level, I then re-imported the users and added them to the relevant teams which seemed to sort the problem - does this work for you if you haven't already tried it?

While this locks down a particular Stream, I'm not sure how you would go about locking down an individual component within a stream - I'm not sure that this is possible, but if it is can you write the steps up?
In RTC 3.0.1, support was added for restricting access to a stream or component based on team area. Before 3.0.1, access was deferred to the project area even though the artifact was owned by a component. This is why removing users from the project area changed the permissions (given that the project area restricts access only to its members).

Robin, double-check the component owner. I believe you have to set the owner of the components to Team B in order to use the process your customized process. Otherwise, the components use the process from the project area that owns the components.

permanent link
Alan D (15631311) | answered Mar 28 '11, 4:40 a.m.
Hi Robin

I found that adding / removing users from the Team Areas had very little impact, unless one removed all users from each Team Area, and also removed all users from the Project Area as well (this last step appeared to be the key). Once the permissions were set up at both the Project and Team Area level, I then re-imported the users and added them to the relevant teams which seemed to sort the problem - does this work for you if you haven't already tried it?

While this locks down a particular Stream, I'm not sure how you would go about locking down an individual component within a stream - I'm not sure that this is possible, but if it is can you write the steps up?

permanent link
Robin Parker (32633738) | answered Mar 25 '11, 12:05 p.m.
Hi Guys,

I''m trying to set up something very similar to this...

I have two teams and two components and 1 stream.

I need one of the components to be read only (as in you not deliverable to) for one of the teams.

I have managed to set this up with 2 streams, the downside being that the users then need to workspaces which is manageable but not ideal.

Then I saw mention above of the operational behaviour and have been playing with it with unexpected results.

In my test, there are 2 teams: Team B and Team C. 2 components, B and C and 2 users user 1 and user 2.

Team B has both users, Team C has only user 2.

There is one stream owned by Team B. I have customised the process for Team B so that only Team C can deliver to the C component.

For some reason I can still deliver to both components as user 1 who is not in Team C.

Can you advise me on the best way to achieve what I'm after?

Many Thanks,

Robin.

permanent link
Ralph Schoon (63.1k33645) | answered Mar 25 '11, 3:51 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
Hi Alan,

thanks for the heads up.

You might want to consider writing a work item. The save work item issue should be solvable with setting the right permissions.

Ralph

Well, kind of solved it, adopting a Year Zero approach.

I have a Project Area with two Team Areas (Dev Team & Prd Team) and two Streams (Dev Stream and Prd Stream).

    Remove everyone from the Team Areas. Save.
    Remove everyone from the Project Area. Save.
    Remove all Process Customisation 'Permission' Settings for the Team Area. Save (stop saying 'save'!).
    At this point, no-one can do anything!
    Set the owner of the Development Stream to the Dev Team.
    Set the owner of the Production Stream to the Prd Team.
    Import user to the Dev TEAM AREA, not the Project Area.
    Open the 'Team Area', click 'Process Customisation' tab, select 'Permission'
    Choose the Developer role. Apply 'Source Control' options from 'Permitted Actions'.
    In the Dev Team Area, apply the developer role to the imported user.
    Get user to perform a Delivery to the Dev Stream, this should work.
    Get user to perform a Delivery to the Prd Stream, this should fail.



At this point, you can start configuring the other Roles and Permissions for the Team Areas.

I noticed though that unless users are imported into the Project Area (not just the team area), they may have trouble saving work items.

I got there, but it seems like a Long Way Round, almost as if RTC is caching the original user settings and not allowing these to be restricted once set.

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.