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.
This one is a bit further down the backlog, but we’re paying attention to it and would no doubt LOVE to make it happen. We’re working on ways to move it up. Hoping it’s something we can make happen in vNext.
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
@John R: The way we're planning on hiding them is by putting them in a category in the process template. We wouldn't break your scenario if you have existing team projects you use and you upgrade to the next version. Your shared steps will continue to show up. On new team projects, shared steps (and other new artifacts we're introducing in the next version) will be hidden by default, but you can go and turn them back on by editing the category if you want. Let us know if you have any feedback on this approach.
Martin Hinshelwood commented
@John R, I do not think that this will be the case, and you would be given the choose as to wither you hide or not. :)
John R commented
We use shared steps as a preconditions to our test cases and our testers in web access filling out fields on shared steps for approval for the shared step to actually become a precondition across test suites. We can't afford Test Professional for 45+ testers so we have 8 Test Pro licenses and then we use web access to have most of the information filled in by the users who just have TFS CALs....we've looked at Sela Web Test tool extensively as well....will this model be broken in the next version of TFS by the fact that you're hiding certain work item types?
Work is on the way in this area. Great suggestion.
Martin Hinshelwood commented
As usual Neno expressed the best ideas