July 15, 2011
Configuring File Access Permissions in Surround SCM
In a recent post, I discussed how to use security groups in TestTrack to simplify the Item window. In this post, I'm going to cover Surround SCM security groups, specifically the permissions that control the access to files. To access security groups go to View > Security Groups...
Understanding File Access Permissions in Surround SCMSurround SCM provides three levels of file access permissions, and these are set for each security group.
Default SecurityThese are the permissions that will, by default, apply to all files on all branches and repositories. These are set on the Server Security tab of the Security Group window. Under the "Files (Default)" category you specify the file access permissions that will be the default for all branches and repositories. In the following screenshot, you'll see that the Dev Team has all file permissions enabled except Destroy on all branches and repositories across all mainlines. [caption id="attachment_9031" align="aligncenter" width="230"] Edit Security Group Window[/caption]
Repository SecurityUse Repository Security to set permissions for a repository across all branches. These are set on the Repository Security tab in the Security Group window. Repository Security permissions will override any permissions set in the "Files (Default)" category on the Server Security tab. In the following screenshot, you'll notice that the Dev Team cannot access the Marketing repository at all. Because the repository is the root of the Mainline, the Mainline branch is not visible to members of this team. The Dev Team also has limited access to the WysiCRM repository. Remember, repository security applies across all branches. [caption id="attachment_9034" align="aligncenter" width="331"] Repository Security[/caption]
Branch SecurityUse Branch Security to set permissions for a repository in a specific branch. These permissions will override any "Files (Default)" Server Security or Repository Security permissions. In the following screenshot, the Dev Team has no access to the Wysi CRM 1.x branch. They do not even see it or know that is there. [caption id="attachment_9037" align="aligncenter" width="410"] Branch Security[/caption] To make the Branch Security tab available, you need to set the branch to use its own security. You do this in the Properties window of the branch as shown below. [caption id="attachment_9082" align="aligncenter" width="330"] Branch Properties[/caption] Note that you can also set branch security in the Properties window of a specific repository in a specific branch. The main difference is that you can configure multiple security groups at the same time, as shown in the following screenshot. [caption id="attachment_9051" align="aligncenter" width="410"] Repository Properties[/caption] Use the Security Group window to set branch security when you are configuring a single group, such as when you configure a new security group. Use the Repository properties window when configuring the security for a specific branch and repository across many security groups, such as when you add a new branch or repository to Surround SCM.
Approaches To Configuring File Access Permissions
Keep It Simple!Surround SCM allows a user to belong to more than one security group. This is a useful feature because you don't have to create a security group for every possible role that your organization may have. But don't go overboard! If you have a user that belongs to five security groups, and each group has repository and branch security enabled, it may be difficult to answer "why doesn't this user see this branch?". In case you do encounter this situation, the Security Group Comparison Report should help you figure out permissions.
All Off, Some OnOne approach is to set the default permissions to none. This would hide all mainline branches from users by default. You can then use repository and branch properties to specifically set the branches and repositories that the group should have access to.
All On, Some OffAnother approach is the opposite of all off, some on. In this approach, set the default permissions to all (maybe except destroy). Then use repository and branch security to specifically set the branches and repositories that the group should not have access to. The best approach will depend on the security group you are configuring. If a group is going to be very limited to what branches and repositories are accessbile, it may be easier to start with the All Off, Some On approach and then enable the few repositories and branches that the group should have access to. On the other hand, for a group that should have access to most of the branches and repositories, it would be easier to start off with the All On, Some Off approach, because you would only need to configure permissions for a few branches and repositories.
Words of WisdomHere are a couple of things to keep in mind when configuring file access permissions at the repository and branch level:
- You should always have a security group that has permissions to access and see everything.
- In order to see a child repository or branch you need to be able to see its parent.