As you know, in TFS 2013, from a permissions point of view, we have 3 licences available to us:
Stakeholder
Basic
Advanced
As far as I am aware, Advanced is the only way of accessing 'TEST' area (Test Case Management), however, is it possible to create 'custom' security licences as we would like to give access to certain users to the 'TEST' area but not have them access other areas where they can create other WITs or potentially modify open WITs - We just want them to be able to view and run Test Cases + create a BUG where required.
We are using TFS 2013 On Premise.
No, we cannot achieve that. We cannot custome the access levels to add/reduce the supported features for each level.
For TFS 2017 and earlier versions, you should assign the Advanced
level to those users for whom you've purchased the full Test feature
set.
Advanced access level include all Basic features. And TFS doesn't provide a more granular permissions settings. So we cannot restrict the users who in Advanced access level to only view and run Test Cases + create a BUG. That is contradictory. We can only set the user permissions based on the existing options.
Please see About access levels; Change access levels and Permissions and groups in VSTS and TFS for more information.
Related
My TFS installation in on premise and I would like to add users to a project allowing them to create and edit work items, but not work as a developer who can create branches or check in code. Is there a default group like that?
I do not see anything in the permission list that mentions code rights.
That's exactly what the stakeholder access level is for. Access levels are different from security groups. Stakeholders don't even have the ability to see the Code tab.
I'm struggling with understanding if it is possible to hide certain tabs from TFS web interface based on specific user group. What I'm looking for is to hide Build/Release , Code tabs and if it is possible the configuration option (the gear button). From what I could find there was a "WorkItemOnlyView" default security group in previous versions of TFS that looked like what I wanted. Is it possible to accomplish something like this now?
You could make them "Stakeholders" access which removes their access to code/builds/release entirely in web portal. Then should see the web portal such as below screenshot:
Another way is restricting access in VSTS and TFS.
Not exactly like this - How to publicly share a Visual Studio Online Repository? - I am trying to share the source code repository (Git) from Visual Studio Online to registered stakeholders. They need to get at the latest stuff at the Master branch to eval it along with work items. How can I do that?
Thanks.
If you have people with a Stakeholder license they won't be able to see the code. The Stakeholder license only gives access to:
View team dashboards and portfolio backlogs
View, add, and modify items on the backlog
View, create, and modify work items such as stories, features, and bugs
View, create, and save queries
Create and receive alerts when changes are made to work items
Submit, view, and change your feedback responses.
For people to see the code, they will at least need a Basic license. If you then want to restrict their access, you can do so by creating a TFS Group and setting the correct permissions. In this case, you want to limit the Code permissions to only Read so they can't modify the code.
See Permission reference for Team Foundation Server for more information.
This means there is no free way to allow users to read your code. You do start with 5 free basic licenses however, so if that's enough you can assign those to your users.
I am unsure whether this is the correct stackexchange site to ask this question, however it is about software tools commonly used by programmers (sort of).
I am collection administrator of 100s of .net projects that I have recently migrated from an on-premise TFS to VSO. I am receiving requests from developers to grant them permission to create/manage test plans.
Now, these developers are members of the "Developer" and "Contributor" groups and as such have the following permissions:
But even so, they are unable to create test plans (using Microsoft Test Manager 2013). I have searched throughout the VSO control panel and I cannot find out why my developers don't have permission to create/manage test plans.
Even the documention provided by Microsoft seems to fall short when it comes to managing permissions in VSO.
Any help is much appreciated. How do I grant my developers these permissions?
Edit: I should add that I myself am able to create test plans. I have compared my permissions in a given project with one of the developers and they are pretty much equal (with some unrelated exceptions like deleting projects).
You can control the "Manage test plan" permission on area node level.
Go to area part, right click on the area your test plans belong to and then click on "Security"
Now you can grant rights for managing test plans:
If the area "Manage test plans/suites" permissions are set to allowed as suggested above and you still can't create test plans, don't forget to adjust the Access levels of your user!
Basic users (which should be default) can't access the test case management even if they have the right permissions.
This does not work in the local install I have done. It is stating that advanced permissions is deprecated. And the link to learn more goes no where.
For those that haven't found a solution even turning all the options provided in Elena's answer, you can check this out:
https://developercommunity.visualstudio.com/content/problem/80055/cant-add-a-new-test-plan.html
It seems that Microsoft ask you for a subscription in order to manage test plans. If the user doesn't have a subscription, even if you add him to the project administrator group, he won't be able to create test plans.
You can limit "Check-In Policy" rules via the "Custom Paths" policy. But the "Check-in Notes" tab doesn't seem to fit in to the same system. Why isn't "Check-In notes" just another "Check-In policy"??
I'm using Team Foundation Server 2008 SP1
We had a similar problem some time ago. For some sub tree we wanted to require entering a code reviewer. I ended up implementing a custom policy and used the Custom Path Policy to restrict it to certain folders. That works well, except that you have to deploy your policy assembly and TFS has no built-in mechanism for that, yet.
That's an interesting question - the short answer is you cannot.
I have ran into the issue myself a lot where people get check-in notes and check-in policies confused because, while very different in implementation on the server, they often serve similar purposes.
Check-in notes are bits of structured meta-data that you want to collect on every check-in to a Team Project. They can be thinks like who was the code reviewer or a reference to a ticket in an external CRM system or something. You can make them required, or just have them defined for people to optionally fill out.
Check-in policies are bits of code that run on the client at the point of check-in that get a say if the check-in should be allowed or not. These are useful for checking things like you have associated a check-in with a work item, given it a comment or the code you are check-in in passes certain key static code analysis rules (such as basic checking for SQL injection attacks etc). If a check-in policy fails in the evaluation of the check-in then the user gets alerted and they get the ability to fix the problem or check-in anyway with a check-in policy override than can easily be reported on or alerted for by the TFS administrator.
Both check-in notes and check-in policies are defined and scoped at the Team Project level. However, Microsoft got feedback that some people would like check-in policies would like to be applied to specific paths in version control rather than just the Team Project and so the Custom Path Policy was invented.
The Custom Path Policy is a bit of a hack that allows you to wrap check-in policies inside the custom path policy. The custom path gets evaluated on every check-in and if it contains files inside the defined path then the wrapped check-in policies are evaluated for those files. The Custom Path Policy ships in the TFS Power Tools and is not part of the "Out The Box" TFS experience.
So, to answer your question a different way - I suspect the answer is "because that's the way it was designed and not enough people have asked for it to be changed".
If you wanted to leave feedback at http://connect.microsoft.com/VisualStudio I know they take customer feedback very seriously.