I suggest you ...

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.

601 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    NenoNeno shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    15 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • techSagetechSage commented  ·   ·  Flag as inappropriate

        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 GreenDavid Green commented  ·   ·  Flag as inappropriate

        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!!!

      • techSagetechSage commented  ·   ·  Flag as inappropriate

        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.

      • KBowerKBower commented  ·   ·  Flag as inappropriate

        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.

      • etropicetropic commented  ·   ·  Flag as inappropriate

        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 MorganRichard Morgan commented  ·   ·  Flag as inappropriate

        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.

      • JWSJWS commented  ·   ·  Flag as inappropriate

        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?)

      • SaraSara commented  ·   ·  Flag as inappropriate

        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.

        Thank you!

      • Ravi BavanariRavi Bavanari commented  ·   ·  Flag as inappropriate

        What Neno suggested above is what we would like to have, please make changes as Neno suggested.

        Ravi

      • John RJohn R commented  ·   ·  Flag as inappropriate

        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

      • Visual Studio teamAdminVisual Studio team (Product Team, Microsoft) commented  ·   ·  Flag as inappropriate

        @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 HinshelwoodMartin Hinshelwood commented  ·   ·  Flag as inappropriate

        @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 RJohn R commented  ·   ·  Flag as inappropriate

        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?

      Feedback and Knowledge Base