How to setup streams with different access control to components for external access
Accepted answer
Create a separate project area for each logical "read access control list".
Commonly in the above scenario, there will be:
- an "internal-only" project area, for the artifacts that should only be visible to internal teams
- a "public" project area, for the artifacts that should be visible to the internal teams and all the external teams
- one "external-x" project area for each external group x, which contains the artifacts that should only be visible to the external x teams and internal teams.
If one encounters the need for a different read-access control list from one of the above (such as artifacts that should only be visible to internal teams and external x, y, and z teams), a new project area would be created for that particular read-access control list.
Then a component or work items would be assigned to the project area with the appropriate access control list.
For streams, since to see a component in a given stream, one needs read access to both the component and the stream, it is commonly "safe" to make a stream visible to everyone, since they can only see the components that they have read access to. But if there is a stream whose existence should only be known by a limited set of teams, then you would assign that stream to the project with the desired access control list.
Note that in order to make this manageable, you would want to used a shared master process project area, so you aren't maintaining separate process descriptions for each project area.
In addition, you would want to script the addition of a person to a project area, because a given person (especially a member of an internal team) would need to be added to multiple project areas.
Comments
We will go with the approach of having multiple project areas for permissions of components. Even though this technique is cumbersome in terms of managing users & permissions throughout the project areas, this is more sensible in terms of organizing components access rights.
Note: I think this might have been answered before 'access groups' became available for SCM artifacts. The answer above is still acceptable, but this feature might add extra flexibility on how to define the read access of components/streams (ex: you can define an access group of 'internal' and another one of 'internal'+'external')
In RTC 6.0.1 the ability to read protect SCM artifacts for a select group of users, project area members, or team area members, by means of an access group was added. Streams, repository workspaces, components, files, or folders can all have their read access determined by an access group.
This new feature is briefly described in the 6.0.1 New and Noteworthy here:
https://jazz.net/downloads/rational-team-concert/releases/6.0.1?p=news#access-groups
There is a jazz.net article called "Controlling access to source control in Rational Team Control" which explains this new feature in a little more detail here:
https://jazz.net/library/article/215#access_groups
There is also a YouTube video showing how to use Access Groups for SCM Artifacts here:
https://www.youtube.com/watch?v=TJM56oVQNMc
Hi David, Thanks. Yes noticed it in RTC 6.0.1 but not sure if it's easy to script the access groups.