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.
Sometimes it may take a bit for the permissions to take synchronize.
http://msdn.microsoft.com/en-us/library/ms400712.aspx#doesnottake
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.
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:
http://blogs.msdn.com/mohamedg/archive/2009/03/23/deny-revisited.aspx
http://blogs.msdn.com/dstfs/archive/2008/12/12/how-to-allow-access-to-a-child-folder-without-allowing-access-to-the-parent-folder-in-tfs-source-control.aspx
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
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.
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.
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.
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
In my scenario this error was fixed when I was added to the admin group for the project.
Related
Recently my team upgraded to TFS 2017 from TFS 2012. I am a TFS administrator on the box but when i attempt to install a gallery extension in a specific team project collection i get:
"Access Denied. {user} needs Manage permissions to perform the action.
For more information, contact the Team Foundation Server administrator."
that would be fine, except i am the server administrator...sigh. the steps i have taken so far are:
reapplied my Admin Console User access.
confirmed i am still a member of the "Project Collection Administrators".
made sure i was in the "Project Administrators" groups for all of the collections projects.
made sure i had allow on "edit/view project-level information" for all projects.
compared security rules between other team project collections and the issue collection.
used TFSSecurity to directly set permissions again.
When i found that none of these steps worked i went so far as to ask another admin to remove me and add me back, to no avail. i should also mention, i have the ability to add extensions in other team project collections, just not the main one we use for development.
Any thoughts would be greatly appreciated.
UPDATE:
We found a post about there being a bug in the RTM version of tfs 2017, we were skeptical that is the cause as we had already done the potential workaround without success. We have decided we are going to attempt to install update 1 to see if that resolves the issues. I will update with the result, but that will not happen until the next maint window.
UPDATE 2:
We installed TFS 2017 U2RC2, and it did indeed resolve the issue. I suspect that Update 1 was all the farther that would be needed, but there are a bunch of nice features with U2RC2.
I'm afraid your issue it's possibility not related to that bug in RTM TFS2017. The bug is more related to the security ACEs for collection admins at the team project level and thus, collection admins were unable to access and administer some team project resources.
To narrow down your issue, you could try below ways:
Use another Admin account to install the specific extension
Use your account to add some other extension
If this is a issue only related to your account, there must be something wrong with the security ACES. Double check and compare the different permission settings between your account and other admin's account. Check if you have any related deny permission under the project collection. In TFS deny trumps allow.
Moreover when you do the remove and add back operation , there maybe some identity synchronization problem in TFS. Waiting for sometime, you could try to install the gallery extension again.
Of course, you could also update your TFS server, which may do the trick. Suggest you directly update to TFS2017 update2 RC2, which will be the last “big” feature release for TFS 2017. Release Notes
I'm working with TFS 2015 using the ALM Rangers Development & Release Isolation Branching Strategy and Team Foundation Version Control. I would like to keep developers from checking code into the Main branch and letting them only work in Dev and Release branches. I want to allow the Project Administrators and above to perform the merges and check ins to Main.
With Team Web Access:
I selected the drop-down next to my Main branch and selected
"Security".
Set Inheritance to "Off".
For Contributors, Set Check in and a few other permissions to "Deny".
Saved Changes.
For Project Administrators, set the same permissions to "Allow"
Saved Changes.
TFS changed the values of each of the Project Administrators permissions to "Inherited deny*"
I have heard that setting "deny" can cause problems. Now I understand why I was told that. Is there a way to achieve my stated goal above, through standard TFS permission settings?
Cann’t reproduce your problem with the same settings in my TFS2015.
According to TFS permission setting, most groups and almost all permissions, Deny trumps Allow. If a user belongs to two groups, and one of them has a specific permission set to Deny, that user will not be able to perform tasks that require that permission even if they belong to a group that has that permission set to Allow.
To achieve what you want, you can create a new group such as DenyMainGroup. Adding the developers to this group. Make sure your project administrator members don’t belong to it. For this group, set Check in and a few other permissions to “Deny”. For Contributors and Project Administrators, set the same permissions to”Allow”. Saved Changes.
Source Control at my client's is a mess. Each developer or team decides where in the source code structure they are going to add a project's root folder and the name of that folder. There is no consistancy, and the number of projects (both viable and dead) make it nearly impossible to discern where your desired project is located and whether or not it is a "live" version. I know from experience that there is not enough discipline for an "on your honor" policy of location and naming standards as a solution.
So, I want to create a permissions based "Policy" whereby the dev/dev team needs to come to an administrator to have an appropriately located and named folder created for the root of their project. Once created, the dev/dev team will be assigned rights to created folders underneath the root of their project folder.
However, I am not seeing an appropriate right from the Folder/Properties/Security dialog to allow/deny the ability to create a sub-folder, so I'm not certain how this could be done.
Ideas? Has anyone faced a similar challenge and how did you deal with it in TFS?
The only thing I can think of is a Custom Check In Policy that check in if any of the Pending Changes are Folders (maybe allow delete/merge status) unless your username is in a set list.
I'm not sure how you would grant access, maybe get someone "approved" to create the folder, or give the changes to an "approved" user in a shelfset and get them to check it in for you.
We are trying to follow the branching strategy from the TFS Branching Guide and have reached the point where we have made a branch representing a release, which should now be made read-only.
In the Properties|Security tab for the branch, it presents six user groups each with 10 permissions other than Read. Do I have to go through and click Deny on 60 check boxes, or is there a better way to make this branch read-only?
Right-click the branch in the Source Control Explorer, and select the Lock... option
EDIT:
This seems to get missed a lot when people are finding this so I'll make it more obvious.
Locks appear as a "pending change" for the person who locked the item. As long as the lock is in effect, it will appear as a pending change. When a commit is made of that pending change, the lock is released. While the lock is in effect, the locked branch is effectively read-only, since (to simplify) the locker is the only user who can make commits. The act of committing is what releases any locks on the branch.
h/t #AakashM for pointing that out in the comments
As a quick-n-dirty, you could Lock it for Check Out (although the locker would have to remember to keep the lock in their pending changes forever... which makes me think there's a better way)
To answer the 2nd part of the question -- removing or denying the Read permission effectively denies everything else.
As is mentioned above locking is not a very nice strategy. The correct way of handling this is setting permissions.
You can effectively make files readonly. Users trying to modify the files will get a message 'checkout denied'
https://msdn.microsoft.com/en-us/library/ms252587.aspx#project_level
In VS2013: Team Explorer -> Settings -> Security/Version Control
Deny Check In for domain\domain users
If you have inheritance set to 'On', the best way I've found is to:
'Deny' all permissions except 'Read' to the 'Reader' group, and
Add all other groups (except Project Administrators) to the 'Reader' group.
Then, all groups within the Reader group will inherit the 'Deny' permissions and not be able to do anything but read.
As part of a maintenance, I was about to Lock several now-obsolete TeamProjects, by right-clicking on each one's root in Source Control Explorer ($/TeamProject) and selecting "Lock..".Once I was done, I tried to commit these changes, which was denied with the following message:
By searching around I bumped into the following statement, made as part of this discussion:
Locks are applied such that the user who places the lock can
checkin/checkout files but noone else can until the lock is released.
So as a more valid test you will need another user to attempt a
check-in of a locked file - ie not you because you put the lock on.
If this statement stands, using 'Lock' was all together not what I should have gone for. What I actually need is to close down older TeamProjects so that no checkouts can occur anymore. How do I do that?(I suppose I could include in my changeset a misc code change, but I 'd go for something like this only if there were no other options available)
As I understand selecting Lock allows you to check out the file in isolation. But doing so will show the project in pending changes window. And i guess this is not what you want.
Team Project Collections can be stopped from the TFS Administration console, however this functionality is not available for individual team Projects, you can vote for this feature here ... http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2485699-make-it-possible-to-disable-team-project
You could right click the team project and select security, change the permissions for the users to read only so they have no check in permissions.
HTH