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.
Related
I would like to know how I can secure an Area (folder within project) - i.e. give access to external consultants for reading and writing.
But I do not want them to be able to access other folders within that Project.
I know how to assign access to the folder (defined Area), but I'm not sure how I can safely remove their rights on the Project without cutting off their access to the folder (Area).
Any help appreicated.
It depends wither you mean Area Paths or Source Control folders.
!!Source Control
In TFVC you can open the web access and go to the code tab. There you can right click on any folder and select permissions. Her 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.
!!Work Item Tracking
If you open the web access and go to the administration section (cog on top right) and then the Area Path tab you can control the permission in the same way you can with source code. If you have VSTS or TFS 2015 Update 2 you can also control inheritance.
!!Real solution
However any sort of compartmentalisation comes with significant overhead of managing it. If you are a defence company or bank and there is that one folder that you don't want externals to have access then it's easy. Remove inheritance for that folder and only allow specific access.
Anything more and you run into complexity and friction for users. Ultimately you should trust everyone you give access to your Team Project. Ifnuoy don'ttrust them, then don'tgive them access...
Go to the Administer Server page and create a new TFS user group.
Add the users to the TFS user group.
Go to the Code screen, right click the folder and choose Security. Next add the TFS User Group you create and give them the rights you want:
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.
I have a very strange situation.... After migrating from StarTeam to TFS (using TimlyMigration == awesome) there is one oddity.
When I look at any given file in the Source Control view, I see all the history that was migrated. However if anybody else on the project looks at the file, the don't see the history. it sounds like a permissions issue, but even if I change their group membership adding them to project administrators they still don't get the history.
So I'm wondering if there is perhaps a problem with the resposity, and if there is an internal consistency checker for TFS that I could be running.
Does the history include any renames/moves? TFS permissions are based on paths, so if people don't have rights to the "old" path then they won't see the history entries before the move.
One other thing to look into is the permissions in the source control (assuming you have given permissions to the project).
In the Source Control Explorer right click on the project and select properties. Then select the security tab. Users should not need to be added to this, but I have had to do it in some cases.
Vaccano
If I've created a label in TFS, assigning it to several files, my coworkers cannot change the versions of files (nor add other files) to that label. We get this error:
TF14077: The owner of a label cannot be changed.
Researching the problem, I found this article, which states:
It is possible that a user could be
allowed to manipulate a shared label
in the development folder but only
manipulate labels that they own in a
production folder.
(emphasis mine)
Try as I might, I can't find any reference to "shared labels". So far as I can see, a label must have an owner.
FWIW, what I'm trying to do is employ a "floating" label so that developers can indicate that their code is ready to become part of the build by tagging it with a particular label. Then the build process would just need to get everything having that label, and automatically get the most recent stuff that's actually ready to be built, ignoring both past versions as well as newer stuff that's not ready for prime time.
Update:
I figure if I can't make a truly shared label, I can at least give users the right to edit labels created by their coworkers. This is pretty explicitly supported. Regular Contributor users don't have this right, but according to MSDN (see article Team Foundation Server Permissions, under Source Control Permissions), it can be granted by way of the LabelOther permission:
Source control permissions are
specific to source code files and
folders. You can set these permissions
by right-clicking the folder or file
in Source Control Explorer, clicking
Properties, and on the Security tab,
selecting the user or group for which
you want to change permissions, and
then editing the permissions listed in
Permissions. You can set these
permissions by using the tf
command-line utility for source
control.
...
Administer labels | tf: LabelOther | Users who have this permission can edit or delete labels created by another user.
So I've assigned that right to the Domain group that contains all the developers, as suggested above. I can verify that it's set using the tf permission command:
tf permission /group:"CORP\Web Team"
and the result is as expected (I also assigned Label, just for fun)
===============================================================================
Server item: $/Test1/TeamBuildTypes (Inherit: Yes)
Identity: CORP\Web Team
Allow:
Deny:
Allow (Inherited): Label, LabelOther
Deny (Inherited):
Yet my test user still is not being allowed to edit a label I created.
Would shelve sets be a better solution for what you are doing? IIRC there is a fairly rich API for working with shelve sets such as committing them as part of a build (or other) process.
I found labels in TFS to be very limited when I used it.
I never was able to make this work with labels. Instead, we devised a whole different process using branching, which I now strongly recommend to anyone reading this.
We set up a branching scheme so that there's a general development branch; from that, each developer has his/her own branch with which they can do what they want, and there's a Production branch.
Developers do their "dirty" work in their private branch without fear of accidentally releasing stuff, or even interfering with their coworkers.
When they've got something ready to integrate they merge the changes into the development branch. We do continuous builds there, and test the results.
When an integrated build is fully tested and ready for deployment, the changes are merged to the Production branch. This is built and deployed.
I had said I wanted
what I'm trying to do is employ a
"floating" label so that developers
can indicate that their code is ready
to become part of the build by tagging
it with a particular label.
The scheme that I outlined above fully achieves this, and more.