Hide Work Item Types (WITs) based on permission/security group
This suggestion is migrated to Developer Community. Please use below link to view the current status.
Within a team project, you should be able to specify who is allowed to create a specific Work Item Type.
A user should only see Work Item Types in the "New Work Item" menu (Team Explorer, TEE, Team Web Access), that the user is allowed to create.
As explained in this blog post (http://blogs.msdn.com/b/visualstudioalm/archive/2015/10/08/how-we-use-user-voice-to-make-a-better-product.aspx), we had updated the status of this suggestion to “Under Review” to let you know we are tracking it on our backlog. To better indicate which one we are actively working on or which ones are on our 6-month plan, we introduced the states “Started” and “Planned”. The goal is to give an update on in progress suggestions at least every 3 months. This suggestion is still on our backlog, but they are not part of the 6-month plan.
Thomas Pagram commented
Is there any updates on the status of this one? It's critical for enterprise scale adoption of VSTS.
This still hasn't been implemented? I cannot find anything on how to do this except to "disable" the WIT, which isn't what we need at all! Any ETA for this?
I saw that if I had migrated from TFS to VSTS I would have been able to do this with the custom XML process, but as I didn't I don't seem to have any options.
Mikael Petersson commented
We have a strong need for this since we have work item types that contain information that we are not allowed to share with off shore employees. As it is now we have to remove permission to the entire project and all processes will be messed up. I was hoping for this in TFS 2018.
It's also useful if the read permission for different work items types can be set.
What is the best practice till now.
Nikki Bridwell commented
Adding the ability to assign work item types to user groups would be a huge help to our organization. I open our portals to our support team to enter a custom escalated work item type. The support team should not have access to enter issues as Bugs directly without being validated. Our dev team closes the escalation and creates a valid Bug to schedule. Now they can see all of our work item types from the widget on the dashboard.
Richard Shadman commented
Tore: If you want to just hide them, import a new category xml with all work item types in the "Hidden" category. Hiding a work item across the board is fairly simple in that regard, but what would make this feature great is being able to make it group/team/security dependent.
Angela Dugan commented
If you want a hack customization that gets you part of the way here while this is being voted up, this might be helpful: http://www.tfswhisperer.com/post/2013/01/14/Making-TFS-2012-Work-Item-Types-Read-Only-Based-on-User-Roles
As I admit in the post, it is NOT an awesome user experience, but it's what you can do in a reasonable amount of time.
I want to access only TFS work item access field only using c#
. any body one help me
I want to access only TFS work item field only using c#
. any body one help me
I am out of votes, but I would really like this one too. We have a few legacy Team Projects where we do not use Work items at all. It would be nice to simply being able to hide the "Work Items" hub and the "New Work item" menu in VS + the Work hub in TWA.
Keith Yin commented
We really want to have a way to keep developers from seeing or changing the features/Scenarios that our Product Management group is working on...and we want to keep our Product Management folks from being able to see the tasks and hours developers are working on.
Desperately trying to get my organization to adopt this, but it's a no-go without the ability to allow our customers to create and edit work items (bugs) without needing a paid account in VS Online. Company is even thinking about leaving JIRA because of issues with email notifications from the service, so the time would be right now to get this done. I'm sure there are plenty of orgs out there avoiding this service for this reason.
David Green commented
TFS permissions scoping is a horrific, horrific experience. In my case, I need to mange two sets of teams with different access levels in the same project: Team A has unrestricted access to all work items, while Team B needs to be able to view/edit Bugs only. We don't want Team B seeing other work item types or viewing project tracking information like burndown charts and backlogs. Trying to get the appropriate permissions in place to accomplish this is impossible, as best I can tell, thanks to blanket permission settings that allow for the reading/editing of "ALL project level information" only, meaning users are given work item access in an all or nothing fashion. Whhhhhhhyyyyy!!!!!! Despite the promise of supposedly being able to use areas & area teams to create scoped access, the process as described on MSDN help sites is a byzantine maze of lies and deception. And this is coming from a TFS fanboy. Your enterprise clients need the ability to give users access only to particular work item types. MAKE THIS HAPPEN!!!
Somehow I keep getting sent to this item as an answer by MSFT employees on forum questions regarding adding access to the limited access feature of TFS to TFService. This does not look like what I want to happen, but I will go ahead and vote for it in hopes that it somehow is bunched with the work that I would like to see happen.
I want to be able to hide certian fields on work item forms from certain users...things like when a test cases steps have an action recording associated with them...resctrict other QA folks from being able to manually change the text steps.
And or restrict types to teams. The team break out in 2012 is great and using team=area setup everything is separate. But some teams have many work item types that another doesn't need, and shouldnt create.
Richard Morgan commented
We let our business users create user stories in TFS. We do not want our business users to be able to see our bugs and task break outs. We've tried to use are and iteration security but it's far too difficult.
I definitely agree that you should be able to limit who can create certain work item types based on their group membership - AND - that these specific users simply do not see the option to create these work items. Seemingly having an option in the UI that is not real - is just bad UI. Being able to query and see - but not change - such work items - based on group membership - is still good team visibility though. (Unless there is reason to hide this also - so configurable for create and separately for browse?)
Also in my company the idea suggested by Neno would be a useful usability improvement.
I can also share another use case we have, in addition to the ones already posted in the previous comments:
we have been using TFS in the past years, during which we have moved from a waterfall to a more agile approach. As a consequence, some work item types (like Change Request) became obsolete and were replaced by new work item types (like User Stories).
We still want to to access all Change Requests that we inserted in TFS in the past;
but users don't have write permissions anymore on them, and cannot create new ones.
That's why we would appreciate if the Change Request did not appear anymore in the New work item menu.