Hide Work Item Types (WITs) based on permission/security group
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.
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.
Ravi Bavanari commented
What Neno suggested above is what we would like to have, please make changes as Neno suggested.
John R commented
Thanks for the feedback. Honestly your current approach is really flawed and short sighted. Essentially you are giving me a single off/on toggle category. And that toggle will be turned off by default - I have to wonder are you guys not confident enough in your shiny NEW workitems to turn them by default in new projects?
If I want to hide tasks from Product Management folks in my organization I won't be able too... in the new model, the current approach would would hide them from everyone. That's flawed. I want developers to be able to see tasks so they can enter their hours and hide tasks from product management so that they can't give my developers a hard time that a specific developer's initial estimate of 8 hours was off by 200% because it ended up taking 32 hours.
I want the ability to hide workitems SELECTIVELY based on roles.
Also in the current approach you're limiting the workitems to be hidden in web access, and test manager...but 90% of our Product management users use Team Companion....will they still see Shared Steps in Team Companion?
For Shared Steps specifically our testers showed me that they are using excel to bulk update preconditions and states....will they still be seeing Shared Steps in Excel if they are in this "hidden" category? If I don't want "Shared Steps to be seen in any client...will the current approach of using a single toggle....hide the work item in all possible clients...if we don't want to see it...it should never magically re-appear...should it?
We also have java developers that write embedded code in eclipse and use TEE....they run on linux....in your current model will they will see shared steps (in my opnion they should NEVER see shared steps in their current "Embedded Linux Developer" role)
The good better BEST model in my opinion would be:
Good) Give me a toggle that turns on and off visibility via a list of hard coded clients (Web/Office/Eclipse/VS/3rd Party)
Better) Give me a toggle that turns on and off visibility via a TFS API extension point.
Best) Give me a permission on visibility of workitem templates based on TFS Security Groups