What are my Version Control permissions on Visual Studio Online?

I want to shed some light on how to figure out what your Version Control permissions are in your Visual Studio Online account.  

Some customers have sent us questions like "I can create a team project, but when I try to check-in a file to that project, I get a permission denied error.  Why is that?"

 

Specifically you might see a message like:

TF14098: Access denied: User <you> needs AdminProjectRights permission(s) for <project>.

or

 TF14098: Access Denied: User <you> needs Checkin permission (s) for $/<projectname>/<folder>/<filename>

 

Unfortunately, as of September 2015, the web experience in visualstudio.com does not allow you to self-diagnose why you don't have the permissions you think you should have. So to do this, you'll need the help of a Project Administrator.

Below is a walk through of how a project administrator can figure out why a team member does not have Check-in permissions for their team project. This post applies for both TFVC and Git, although the screenshots below show TFVC.

As a project administrator, navigate to your project's Version Control security page. To do that, navigate to your Visual Studio Online project like this:

ie: https://<youraccount>.visualstudio.com/DefaultCollection/<project>

Click the gear icon in the top right corner to get to the administration site, and from there click the Version Control tab.  You'll see something like this:

 

The problem with this page is it only tells you the default permissions for the various user groups for this project. For example you can see what permissions you get by being a member of the Build Administrators group or the Readers group. However these are just the default values and it does not mean that every member of that group has those permissions. If you are a member of multiple groups, and one group grants you permission, but another group denies you that permission, then your overall permission will be Denied. Since project administrators can add you to multiple groups and customize each group, they can quickly create quite a mess regarding individual permissions.

What we want, which is missing from Visual Studio Online today, is a way to see what the overall permissions for an individual user are. Here's how to do that.

Click the Add... button and select Add User. That will pop-up a window like below. Enter the name of the user in question to add the user to the team project directly, and click Save Changes.

Now the user will show up individually under the Users section as shown below.  Select that user in the center column.  When you do that, the permissions on the right will be the specific permissions for that user.  That's what we need to see! From there you can see in this example that the Check-in permission is set to Inherited Deny.   Hover your mouse over the Deny setting and you'll see a Why? link appear. 

 

Click on Why? to see the root cause of the Deny. In this contrived example I see this:

This tells me that the Deny permission was inherited from the Readers group.  So the fix in this case would be to either remove the Deny permission from the Readers group, or remove this user from the Readers group.  Either solution will work and the end result is the user will inherit the Allowed permission by virtue of belonging to the Contributors group.  In this contrived example, the right fix is to remove the Deny permission from the Readers group; set it back to Not Set.

 I hope that helps!

 

P.S.  I saw another interesting case of this that was caused by the user referencing the wrong project.  This was further complicated by the recent Rename Project feature.  The customer had two projects with similar names, only different by a space.  They had a project named 'FooBar' and wanted to deprecate it.  So they renamed it to 'FooBar - Old' and explicitly denied check-in permissions for all users.  Then they created a new project named 'Foo Bar' (with a space).   The fact the new project name had a space was evidently accidental and not well communicated.  So users continued to use their existing workspaces that referenced 'FooBar.'  That project name technically didn't exist anymore, but we in Visual Studio Online made a big effort to support backward compatibility.  So users with old workspaces that referenced 'FooBar' were internally redirected to the new name of the old project 'FooBar - Old' and these users were getting the permission denied error.  The fix was to update their workspace to refer to the new project 'Foo Bar' (with a space) or rename the new project to be the name of the old project (without a space), reusing the 'FooBar' name.

So check the project name carefully!