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:
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.
I have my TFS server and it has multiple branch like Dev,Test, UAT and Main. my problem is I have some security concern regarding web.config resides under Main branch. I want so access mechanism using which I can apply access permission on single file only.
I need that my team lead can only able to see that web.config file resides into Main branch but my developers can't see it.
how is this possible using TFS 2013?
Yes, this could be achieved. The simplest way is through source control explorer, select the file in Main branch from source control explorer and right click it, choose security.
On the pop-up dialog, you could be able to change the related permissions of this single file xxx.config.
In TFS deny trumps allow, then simply change the read permission for the group of developers from allow to deny.
We use TFS as source control. In TFS we host a solution consisting of multiple Visual Studio projects. We do not want our contractors to see the source code of ONE of these projects (limited users should still see all compiled assemblies). What is the best way to achieve our objective without setting up two repositories and having to synchronize all code changes between them?
I would recommend that instead of just changing the permissions in place that you move the projects that you want to protect to a separate folder with its own solution. Secure that folder as above. You can then build it separately and deploy it to an internal nuget repository.
you can then reference that repository from within the Visual Studio package manager and it will be managed as an external dependency. If you update and publish the other solution then the other devs will be notified of updates..
You control access rights to a folder by selecting Advanced->Security from Source Control Explorer. From there, you can turn off security inheritance for the item(s) you need to protect. Then, create a TFS-specific group containing the 'limited users' only and only allow them access to the particular project folder. Alternatively, create a group for the contractors and deny them access.
This is based on VS/TFS 2012.
But my guess is that you will also need to create a specific solution for the contractors that doesn't have the particular project included.
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.
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