Add ability to hide/mask fields in a work item based on security/permissions
This suggestion is migrated to Developer Community. Please use below link to view the current status.
Currently you can make work item fields READ-ONLY for certain groups of users. We would like to have the ability to hide fields or to mask the value of the field as well based on security permissions.
For example we require our PM's, Dev's and QA's to enter time estimates for enhancements and defects. These are values that we don't want our Sales/Consulting teams and potentially End-Users from seeing.
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.
Sylvia Ward commented
What is the status of this request? I selected the link provided by the Visual Studio Team (see above post Oct 2015) but got an error. I do not see the status (e.g. Under Review" anywhere, and an update certainly has not been made every 3 months as mentioned.
This was requested many, many years ago and has been voted for over 350 times - what is the status?
We need this feature so we can hide some of our internal fields from the bug work item when it is opened up to our customer (who will be in a specific user group) to view the status. As mentioned by someone else, this functionality is available in JIRA, but we are a MS partner, so we have to use TFS/VS. We are using 2017.2 at the moment with plans to upgrade later this year.
Gopi R commented
If this one functionality existed, we would not even be considering JIRA. As things stand, we are currently still evaluating VSTS.
Greg R commented
We need the ability for some work items to be seen by a few people. By default everyone can read work items, Work item handling is not consistent with source control where people can be expulsed from seeing source.
Jason McAdams commented
Another use case that I've been wanting this for... We determine estimates up front from a project management team prior to development for purposes of prioritizing the backlog with operations. The developers also put their estimates on an item when it is assigned to them (we don't know who we are going to assign it to up front, so we can't ask for this estimate until it's ready for development). We don't want the developers to see the PM estimates as it sways their opinions. They don't want to go over that estimate since they feel like it makes them a lesser developer. So they tend to keep their estimate the same while trying to speed up or slow down development to match it. This makes it very difficult to gauge if our PM estimates are correct as well as hindering development to a degree.
Another Use Case:
You have two partners developing software for you. A bug fix needs to be made in two components which are developed by different partners. Then you do not want partner one to see the estimates and costs that partner two computes.