I have set up security in TFS 2012 Team Projects. There is one user who can see parts of a Team Project (certain branches) that he otherwise should not see. I have checked the branch security as well and can't find anywhere why that user should have access to it. It also shows a weird plus sign in front of that Team Project for that user only where he can only see some branches and not the full team project.
figured it out. apparently user had checked out some files before we restricted the permissions and therefore once the user checked in their changes, they could not see these projects anymore.
Related
I have a user who is a stakeholder in VSTS. He needs to be able to access a branch in the project I am working on. So he can work on it then commit to it. I don't want him to see any other projects I have on VSTS. Is this possible? I don't really want him to be able to access the other branches but it doesn't matter too much - hiding the other projects is more important.
Actually people with Stakeholder access level could not commit their work on branch.
Assign Stakeholder access to those users who need to enter bugs,
view backlogs, boards, charts, and dashboards, but who don't have a
TFS CAL. Stakeholders can also view releases and manage release
approvals. Stakeholder access is free.
Source Link: About access levels
See Stakeholder access for details of features available to stakeholders.
The user should have either Basic access or VS Enterprise which include code feature.
Moreover, it's able to forbid him to see any other projects you have on VSTS. This is another concept called Permissions in VSTS. Do not add him to any other project team group expect the one he will work on.
You could also be able to deny the Read permission for branch/folder level
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.
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 know that this is possible for TFS projects, but I seem unable to take care of this. I've renamed TFS-hosted GIT projects with no issues, but I'm not able to see the drop-down menus or text-editing boxes on my TFS2015 Admin Site.
I've tried in multiple browsers, multiple systems. I am a Project COllection Manager, and have verified that I have full rights on all projects to be renamed.
Please provide some input as to how I can further diagnose.
Best,
Larry
You can go to team project admin page, and move your mouse to the Name of team project, the text-editing box will show up, then you can remove the team project:
Another way is go to team project collection admin page, right click the team project you want to rename, then select Rename:
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.
I'm trying to set up our TFS 2008 instance to require that projects build before they can be checked in.
I have created a check-in policy using the out of the box "Builds" policy, but I'm still able to check broken projects in after mangling the code and attempting to build the project.
We're a small shop, and TFS was originally set up with our team's Active Directory group listed as TFS admins. Is this the problem? Do check-in policies apply to TFS admins?
Any other suggestions?
Check-in policies are a client-side check only. If the client does not have the check-in policy available, the check will not run. Instead, they will get a generic policy failure saying that not all policies were run. Additionally, any user (there's no special permission for it) can override a check-in policy failure with a comment.
The "Builds" check-in policy does the following:
Request from the server a list of build definitions affected by this check in
For each build definition returned where the last build was not "good," create a checkin policy error message containing the build definition's name and the user that triggered the build.
If the policy detects a broken CI build, show an error when you attempt to check in. "The last build failed.."
It sounds like you're trying to make sure that people don't break the build with their check-ins. TFS2010 includes a new feature called Gated Check-In that validates changes before they are committed to source control.
If you are using TFS2008 and can't upgrade, you'll need to look at something like OpenGauntlet - however the user experience is much improved with TFS2010.
TFS was originally set up with our
team's Active Directory group listed
as TFS admins. Is this the problem?
This is probably not the best idea. Team Foundation Server Administrators can do destructive things like destroy files+history and delete projects. If there's any chance that somebody might become disgruntled, you might want to reduce the number of admins or ensure that you have good backups.
As a middle-ground, you could have 1 or 2 people as TFS Admins, and everybody else as a Team Project Administrator. Most people only need Contributor access though.
In TFS2010, there is a new concept called "Project Collections". Typically, organizations have 1 or 2 people as "Project Collection Administrators" so they can add new projects and build controllers.
Check-in policies apply to everyone. Did you verify that your deployment of the policy is active on all machines?