What I did, is that I have created a group with few members and assigned it to a branch.
When I login with a user from the restricted group, then I don't see any branches.
Then, added that group to the "Readers" group. Now I see all the branches in the project.
Is there a way to hide all other branches and show only the one that has that group?
Thank you
Git does not support read/contribute permissions on branches. TFVC - yes.
Consider using Forks.
In TFVC you can create a new folder in the root and move the restricted branches to it. Then set the Read permission to all root folders (except the new folder) to DENY for the restricted group.
In this case, the restricted group will see only the new folder and its content.
Thank you all for your answers!
I solved it by creating a new project with readonly permissions. So every time there's a change in the main project a task will be triggered in TFS to push the changes to the other project. That was the only option for me.
Related
I am attempting to undo pending changes for a user that no longer exists in our organization. DevOps will not allow me to work with the workspace or identity at all, indicating the user is not a valid identity:
TF14045: The identity XXXXXXXX, XXX is not a recognized identity.
We don't care about any pending changes, we just want the (shared) locks removed.
Can this be done? Thanks all.
When you run commands to work with the workspace, try using their email address instead of their display name. For example, list that user's workspace with the command below:
tf vc workspaces /collection:https://xxx.visualstudio.com /owner:<email>
Then run tf workspace /delete to delete the workspace.
First make sure you have the rights to unlock others code see here: https://learn.microsoft.com/en-us/azure/devops/organizations/security/permissions?view=azure-devops&tabs=preview-page#tfvc-object-level
Then you should be able to use the TF command to unlock files. See here: https://learn.microsoft.com/en-us/azure/devops/repos/tfvc/lock-command?view=azure-devops
(You'll want to use /lock:none to remove the lock)
I'm also pretty sure that if you delete the workspace of the user that left he lock will be removed, check it out here: https://learn.microsoft.com/en-us/azure/devops/repos/tfvc/workspace-command?view=azure-devops
From this article: "If you delete a workspace that contains pending changes, Team Foundation cancels the pending changes as part of the delete process. Deleting a workspace does not delete the files and folders on the client computer that were in that workspace."
Good luck
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.
Our TFS processes used to use a branch-per-revision technique. Although I've changed that now, we still have old branches from the "per release" days.
When I start a "Merge" from our "DEV" (main, trunk) branch, I still see all of the old release branches as possible merge targets. This is inconvenient.
Short of deleting the old branches, is there a set of permissions I can apply which will keep everyone (including me) from seeing those branches in the "Merge" dialog as targets?
You can deny read permissions on those branches in source control. After doing this, the branch will be shielded in TFS. You can do this in the VS(right click the branch-advanced-security) or using tf permission command
However in your situation, I will recommend you to delete the branch, since you want to applicable to everybody. Delete is the simplest solution, and you can undelete it if needed. Setting permissions are works well when preventing someone to access the source contorl folder. But not the best one in this case.
Is there a way to deactivate a project in TFS? (not delete, just deactivate so nobody can checkout or checkin)
This is more of a precaution rather than a hard enforcement. We have a project that was branched but was recently merged to a trunk. This project is no longer in use and I don't want anyone to accidentally use it by checking in/out any of its content. It will eventually be deleted when we have tested the merge completely
In Team Explorer, right click on the project and bring up Team Project Settings -> Group Membership. Go through each group, click Properties, and remove all users and groups from each group. This should prevent anyone who doesn't have a TFS administrator role from being able to check the code out. It may even prevent TFS administrators from being able to check it out without first adding themselves back to the correct project group.
I think this will work, but you should try it as I've never actually done it.
If you still want the project to be available, somebody could just put a lock on the project to prevent check-ins and check-outs. It will remained locked by the user who locks it until either the user unlocks it or their workspace is deleted. An admin can also unlock it using tf.exe.
You can lock a project, branch, folder, or file by right clicking on it and selecting the Lock option from the context menu (note: what you are locking has to exist physically on your drive). This page describes the various types of locks you can place on an item.
For work, I wrote a plug-in to automatically place a check-out lock on production branches once certain criteria are met. The lock is held by the account running the TFS services (in our case, Network Service). Nobody can check-out or check-in files in these branches until somebody uses tf.exe to unlock the branch.
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.