Restricting Access to a Stream

Hi Alan,

I believe the easiest way to do that would be to use teams.
If a stream is owned by a team you can restrict delivery of changes to certain roles of users of this team.

You could have the developers in one team that owns the Dev stream.
You could have certain roles in another team that owns one or several of these other streams. You could have more than one additional team too.
Users with certain roles can be allowed to deliver to the stream owned by a certain team.

I can't look into the details right now but I think this is a way to do what you want.

Ralph

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.

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.

Is there anywhere that explains each of the RTC icons? I have 2 team areas represented by 2 different Icons and it's not clear what the distinction is.

Hi,

as far as i remember the distinction is that in one team the process is customized. In the other it is not.

Ralph

Is there anywhere that explains each of the RTC icons? I have 2 team areas represented by 2 different Icons and it's not clear what the distinction is.

THanks Ralph

I've got 2 project areas, where both streams have multiple teams and streams.

In one Project Area, I've managed to set up a Team called Release Managers in both Project Areas.

In one of the Project Areas I've managed to limit the scope of a couple of Streams such that only members of Release Managers can deliver code to those streams, using the process customisation at the Team Area level, and set up the Stream owner as Release Managers. I've tried to replicate thisin the other project area, but so far without success. Is there a definative guide as to how to accomplish this?

I should probably have written the steps down myself and published it......!

Alan,

please write it up once you succeed again. 8-)

There are basically two mechanisms you can use. A stream is owned by a team. Users without role with permission to deliver to the stream effectively can't. There is a doc about permissions in the library you can look up. So make the setup that the members that can deliver are members of a team with a special role (access by roles accumulates and users can have multiple roles).

Then there is a precondition to restrict delivery to components in a stream. Similar mechanism of operational behavior, except that the first one found is picked and the order of the roles has a meaning. There is an article about Operational Behavior theory in the library along with the one about permission.

Ralph

THanks Ralph

I've got 2 project areas, where both streams have multiple teams and streams.

In one Project Area, I've managed to set up a Team called Release Managers in both Project Areas.

In one of the Project Areas I've managed to limit the scope of a couple of Streams such that only members of Release Managers can deliver code to those streams, using the process customisation at the Team Area level, and set up the Stream owner as Release Managers. I've tried to replicate thisin the other project area, but so far without success. Is there a definative guide as to how to accomplish this?

I should probably have written the steps down myself and published it......!

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.

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.

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?

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.