I'm trying to change the permission of about 250 folders in Azure DevOps (VSTS), the source control is TFVC, and it is quite slow to change just 10 of them using the web interface.
Is there a command line tool that I can set the permission to a directory? For example, adding the A Contributors group to the directory /Release/v1/ProjectA and B Contributors group to the directory /Release/v1/ProjectB. I'm hoping this way I can just iterate through all the releases.
I was looking at TFSecurity.exe but it doesn't seem to be able to change the permission of individual folders. Or perhaps I missed something?
So, there's a Microsoft VSTS CLI in the marketplace and it has most of the basic commands you'd need. Unfortunately, when looking for permissions and repo security configuration commands, there are currently none.
Taking a look at their GitHub Repo, they do have an open issue for this exact command which would be a new feature.
Sorry!
Turned out TF.exe is the answer. For some reason I overlooked the Permission command.
The following enables inheritance for /Release/v1/ProjectA and adds a set of permission to the security group Contributors A:
.\TF.exe vc permission /inherit:yes "/Release/v1/ProjectA"
.\TF.exe vc permission /allow:"Read, PendChange, Checkin, Label, Lock, Merge" /group:"[Project]/Contributors A" "/Release/v1/ProjectA"
Related
So for "security" reasons I am forced to use a different account to run visual studio for certain admin level operations (registering COM objects mostly). TFS however only knows about my lower level regular account. In the past this hasn't been an issue and I've set credentials up for my admin account to log into TFS with the regular account.
However something has changed since I last did a password change and logging into one particular nuget feed (hosted by TFS / Azure devops server in house) from VS2019 running as admin will lock my AD account. Also my git TFS account seems not to be using the correct account. A different feed hosted by the same TFS instance (the only difference is the feed name) works fine.
I have tried setting credentials for nuget using dotnet nuget update source name -u username -p password and that hasn't helped. I suspect since git gives issues when I push to the TFS server it's using some sort of windows stored user name and password and nuget is using the same invalid credentials. I can login to TFS to search for work items in VS2019 to add on git commits so at least one provider is set correctly.
So my question is how do I find out what the actual username and credential type / provider is being used for a particular nuget feed? Ideally I'd like to find out what username it's using as well.
Please first make sure the account you were logging in with do have permission to the nuget package.
how do I find out what the actual username and credential type / provider is being used for a particular nuget feed?
You should find CredentialProvider in my local folder:
C:\Users\[username]\AppData\Local\NuGet\CredentialProviders\
Use NuGet with Azure DevOps Services feeds
Also give a try with below solution, check if this do the trick:
Right click on your solution from Solution Explorer
Manage Nuget Packages for Solution-> on top right corner click on the gear symbol -> on the left hand-side go to NuGet Package Manager
Package Sources -> on right hand-side UNCHECKED the package source you are having trouble with
Click Ok button -> restart your VS it should only ask you login once
now
.
Okay in my case it turns out different versions of nuget are in use.
The CredentialProviders folder was empty.
However I suspect an older version of nuget was involved that looks in this config file
C:\Users\<your_account>\AppData\Roaming\NuGet\NuGet.Config which in my case had the same repository name twice with slightly different casing (no idea why?) and the password was incorrect on one of those entries (they should all be the same).
So running nuget.exe sources update for the older mechanism as well as dotnet nuget update source worked. I also notice that update source requires a later version of the dotnet sdk than I happened to have specified in global.json for this project.
So I suspect this is mostly down to having
multiple versions of nuget on my machine along with a somewhat elderly dotnet sdk being in use.
The nuget repository having the same name only differing in case
I hope this helps someone else at some point.
I have marked Patrick Lu answer as correct as it actually answers my original question.
I have a solution that contains several projects, I want a team to work on this source code, but every developer can only see his own project and can't see the rest of the projects. But he can build and run the whole solution. What solution do you have for this?
It should be able to achieve this no matter you are using TFVC or Git as your source control.
TFS build is using build service account not the user which trigger build. Once the build service account have appropriate permission, it will get source from TFS server and download to build agent.
The permission in TFS is mutual independence. And permissions can be granted directly to an individual user, or to a group.
In version control permissions, explicit deny takes precedence over administrator group permissions.
You could deny the Read permission for those users. And set the other related build permission such as view build definition and queue build to allow.
Read
Can read the contents of a file or folder. If a user has Read
permissions for a folder, the user can see the contents of the folder
and the properties of the files in it, even if the user does not have
permission to open the files.
Queue builds Can queue new builds.
View build definition Can view build definition(s).
View builds Can view builds belonging to build definition(s).
...
However, there is still some difference for Git and TFVC for control project permission：
In TFVC you can open the web portal and go to the code tab. There you can right click on any folder and select permissions. You can use any fine grain you like and control inheritance.
In Git you can only control permission ls at the Repository and Branch level.
Besides, you may also need a account with full permission of solution and all projects to create the build pipeline. Otherwise, the user may not able to select the mapping relationship in source get configuration.
I have projects from two separate TFS collections that I am migrating to VSO. For this reason, I need two developer groups.
Is it possible to clone a group, with all permissions intact (even inherited ones)?
Unfortunately, there is no clone functionality in the UI or a command line. The closest would probably be to write a script that used tfssecurity to get the membership and permissions for a group and recreate it. There may be additional issues, but it will get you close at least.
I just got assigned at my job to figuring out Team Foundation Server as we are switching to it from PVCS. I was messing around with the source control features, trying to get gated check-in to work, as that is something we will be using in my job. I am pretty sure I set up the build definition correctly, as far as I can tell that is, and I turned MSBuild Multi-Proc to false as I have seen suggested online.
My problem is that when I try to check in a file I get an error for every file in my project stating
C:\Builds\1\TFSTestProject\Gated\src\TFSTestPrograms\TFSTestPrograms\{File} Access to the path 'C:\Builds\1\TFSTestProject\Gated\src\TFSTestPrograms\TFSTestPrograms' is denied.
I don't understand why I would have any access denied and I have looked for solutions all over google and have not found anything that has fixed this issue. My server url is just http://localhost:8080/tfs so I should have access to everything (at least I think i should...)
Another thing is that there is no 'Builds' folder on my C:\ drive like in the path they give
I am very confused about this issue and I have no idea how to fix it.
If you have installed a build server the path that it is objecting to is on the build server itself. You should review the installation instructions for the build server and the account used to set up the build server.
Two lengthy to repost but ben day has an excellent TFS installation guide here: http://www.benday.com/BlogFiles/Tfs2012InstallGuide/BenDay-TFS2012-Install-Guide-v1.0.pdf
Make sure that whatever account you configured TFS and, more importantly, the Team Build service to run as, has full control access to the C:\Builds folder.
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.