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.
Related
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
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.
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.
We have a trunk in TFS that everyone works off until we have a need to branch. Our last project was a large feature that required a branch. Now that the development has been completed and the changes have been merged back into the trunk. What should happen to the development branch?
Should I delete it? Mark it as read-only somehow? What about cloaking and locking?
You can make a branch read-only. You just need to remove the check-in/check-out permissions from the appropriate groups. Note that it doesn't look any different on first blush, but when you attempt to check out a file, you'll be prevented.
I always end up deleting the branch. It's "deleted" but there's nothing preventing you from undeleting it (which is different that destroying) or looking back at the code. It doesn't actually go anywhere unless you go through the effort of destroying it.
In addition, if you have a nice tool like Team Foundation Sidekicks, you can still see all of the branching history, even if it's been deleted.
You can, as #Ray says, just leave it, but if you do that over the course of a dozen or so branches, things become a bit unwieldy to manage. If the branch is dead, and you've merged the code into mainline, do you have any purpose for keeping it around aside from "just-in-case."
If so, just delete it and dig back through it only if you really have to.
Just leave it. :) You can delete the branch but it will still remain in the repository. It really is a decision that you and your team can make to follow your source control guidelines.
On a side note, there is no read-only option in TFS, you can only leave it, delete it or run the TFS destroy command to permanently remove the branch.
There is a Read access control permission. If you set Contributors to "Deny", it should override any "Not Set" or "Allow" permissions. You can set it in Source Control Explorer by right-clicking on the folder and going into Advanced | Security...