15

When I try to check out a file from TFS I get the error TF14098: Access Denied User [username] needs PendChange permission(s) for [path].

I have added the user to the contributor group but it still won't let them check out a file.

riQQ
  • 9,878
  • 7
  • 49
  • 66
Ryan
  • 4,602
  • 8
  • 37
  • 43

9 Answers9

6

Sometimes it may take a bit for the permissions to take synchronize.

http://msdn.microsoft.com/en-us/library/ms400712.aspx#doesnottake

Ryan
  • 4,602
  • 8
  • 37
  • 43
6

This is frustratingly stupid. So, if you're having this similar issue, but you can't find the actual permissions you need to change and can't seem to find where these permissions are set via your IDE, it's because you need to actually access the permissions by right-clicking on the Project and selecting Advanced->Security, not going to Team->Team Project Settings/Team Project Collection Settings->Security. You can do this with tf commandline too using tf special tf commands, but I had issues with that.

kayleeFrye_onDeck
  • 6,648
  • 5
  • 69
  • 80
5

If the user (or AD security group) you modified was already known to the system, changes should be instant. Synchronization only comes into play in the opposite scenario: a security group already had PendChange allowed, then a Windows admin added a new user to that group. TFS won't know about the change until it talks to active directory during the next scheduled sync.

The most likely cause for what you're seeing is permission inheritance. Even if the user is explicitly Allowed a permission, any Deny ACLs that apply to him will override it. For example, ACLs set on a parent item might be inherited. Similarly, if the user is a member of two groups (eg Contributors and Readers), he could have conflicting ACLs in play -- and Deny will always win.

In addition, the model for inheritance was changed slightly in 2008 SP1. See:

Richard Berg
  • 20,629
  • 2
  • 66
  • 86
  • Could it also be that the user was never a member of any TFS groups and the first time you add a user to a TFS group it has to synchronize? – Ryan Jun 23 '09 at 13:53
  • If you add a user directly to a TFS group for the first time, it /should/ be instant. If you add a previously unknown AD group to a TFS group, it will take some time before TFS enumerates the members of the AD group and caches them internally. – Richard Berg Jun 23 '09 at 15:14
3

Using tf perm and tfs ui I found that the PendChange permission was granted by giving the specified usergroup Checkout permissions to the root of the project in the security tab of TFS 2015.

PendChange = Check Out permission

James
  • 31
  • 3
0

In my case this link below worked well

http://ravendra.wordpress.com/2010/06/04/tf14098-access-denied-user-user-needs-pendchange-permissions-for-source-control-folder/

"This will basically tell you list of all users/groups with their permission. From this list check if any the group you are the member is denied for PendChange or its directly denied for you. If yes then take the necessary steps to remove that.

Point to note here is Deny always takes precedence. Let’s say you are member of TFS Admin (where all permissions are allowed) and also project reader (where except PendChange is denied) then PendChange of reader will take precedence and you will not be allowed to delete."

Update:

For TFS 2012 use "Developer Command Prompt for VS2012" and check: https://msdn.microsoft.com/en-us/library/0dsd05ft(v=vs.100).aspx

Glorfindel
  • 21,988
  • 13
  • 81
  • 109
Sandeep
  • 615
  • 6
  • 13
0

Readers permission to be removed from the team project in TFS, This will prevent editing the files.

I have checked this in TFS2013 and works fine.

user3007071
  • 21
0

I experienced the same issue when merging from a child branch to a parent branch. A member of the Project Administrator group itself was not allowed to merge to that branch.

After checking with "tf perm ", made sure there are no Deny permissions for that branch for the group.

After going over lot of places found that there is a delete checkout in that branch attributed to a developer. Found this using "Find in Source Control" -> Status" -> Checkout Find.

Later found that a developer who had access to that branch had attempted deleting the branch (as part of cleaning up) before he was leaving the company. I undid that change (using undo by selecting that checkout) and Presto! the merges started to work.

I'm still not sure how this would have even happened and don't know a cause. But for anyone who face this issue in merges, please check all your checkouts once and if you find some checkouts(such as delete) as weird, undo it and try again. That might be a reason.

lakshminb7
  • 1,602
  • 3
  • 25
  • 31
0

Issue solved.

TFS UI->administer->project->manage project security-> go to version control tab-> select the role.

if user is not able to check-in and rollback need to provide permissions of read && check-in and check-out need to be allowed over there.

-2

In my scenario this error was fixed when I was added to the admin group for the project.

Frank Pearson
  • 872
  • 5
  • 16