It would be very unusual for an organization to allow all employees and contractors the same level of access to all of the organization's files. In fact, I've never seen such an exception-an organization that lets accountants look at source code and developers peek at offer letters. With no exceptions that I know of, different people need different levels of access.
But this "levels issue" involves more than just the ability to see files. It also has to do with the ability to create, modify, and delete files. Different people need different levels of access to different files. I'm being very general here, but that's because this rule of thumb applies to every aspect of an organization's documents, from source code to financial statements.
Like any other software package, Visual SourceSafe 2005 (VSS) comes with access-level defaults. VSS calls them "rights and assignments." In this blog, I'll show you how to set users' rights and assignments so that only people in the appropriate roles can do the appropriate things.
Step 1: Secure the root database folder
You do all the work of administering VSS in the Visual SourceSafe Administration application, a utility that installs along with the VSS editor. To launch it, simply select it from the Windows Start menu shortcut.
If this is the first time you've started the Admin utility, you will get a sternly worded "Security Note" advising you to secure the VSS database with Windows folder permissions (Figure A).
If this isn't the first time you've started the Admin utility, you won't see the Security Note, and yet following its advice is Step 1. (It's easy to click OK on this message the first time you see it and then completely forget about it.) So whether or not you get the message now, start Windows Explorer on the machine that houses your VSS database, find the database's root folder, and do exactly as the message says (I'm quoting it here almost verbatim):
- Enable sharing for the folder containing the VSS database
- Click Permissions and remove the Everyone group
- Explicitly add database users
What this does is deny access to all VSS projects to anyone not in the Group you gave access.
Step 2: Set each user's baseline access The default view of the Admin utility lists the user accounts and their granted rights (Figure B).
The column that says "Read-Write" tells you what that user's baseline rights are. A user's baseline rights are either Read Only or Read-Write. The default is Read-Write, which, generally speaking, means that they can check files in and out. If there is anyone who needs to be able get files from VSS but never check them out or in, set their account to Read Only. To do this, select the user you want to restrict in this way and click Users, Edit User... (Figure C):
You'll see the Edit User dialog box. Select the Read only check box and click OK. Step 3: Set each Read-Write user's rights assignments
The next step is to fine tune the rights granted to the users who have Read-Write access. There are four access rights:
- Read. This right lets users get files, and nothing else.
- Check Out/Check In. This right lets users check files in and out, but never add, remove, or delete them.
- Add/Remove/Delete. This right lets users add files, remove them, and delete them, but never delete them permanently, roll back to earlier versions, or recover deleted files.
- Destroy. This right lets users remove files permanently (purge them), roll files back to earlier versions, and recover (undelete) deleted files.
By default, everyone who has Read-Write access within the VSS database has all four rights on all projects (the $/ level, or root). That's almost always excessive. To fine tune each user's default rights, follow these steps: a. In the Admin utility, select the user whose rights you want to set and select Tools, Rights Assignments for User... (Figure D).
(Note that Rights Assignments are enabled by default; if you find the Rights Assignments for User... command grayed out, you will first need to enable it by selecting Tools, Options, Project Rights, and checking Enable Rights and Assignments commands.) b. You'll see the Assignments for <user> dialog box (Figure E).
This dialog lists all the rights assignments the user has now; if you have never changed this user's assignments, it will show only the default, at the root ($/). In any case, at the very least I recommend that you remove Destroy rights at this level (Figure F).
c. If you do nothing more, this user will have the rights you've assigned to all sub-projects below the root. To add additional assignments, click Add Assignment. You'll see the Add Assignment for <user> dialog box (Figure G).
d. Set the user's rights assignments to one of the projects for which you want to assign a specific level. Isabel is an interpreter in Client Services, so we'll grant her Add/Remove/Delete rights on the Client Services folder (Figure H).
e. Repeat Step d for each project on which you want to set a specific rights assignment that differs from the user's root assignment. Given Isabel's role in the organization, we've granted her Read rights on the root and on the Build projects, but none on Source (Figure I).
f. Repeat Steps a-e for all Read-Write users.
That's it. Although the process may seem tedious at first glance, in fact it takes very little time, and once it's set, you rarely need to change individual assignments. In a small business, it's a good investment of time.
Every organization needs to control access to its digital files. In VSS, it's easy to set individual users' access rights to individual projects. As long as you know what each person's role in the organization is, you can make assignments that give them just the access they need.