Is there a way to hide specific TFS work item types for some user groups? E.g. Client should not see Bugs.
Is there a way to hide specific WI fields. E.g. Client should not see Estimation field.
The only way that I know so far is using the security rights on the WI area field.
That allows you to create specific areas, remove read rights for some users/groups and than all WI in that area will not be visible. The problem is this ads new responsibility to the area field that leads to duplicate tree structure.
I am aiming for more flexibility, maybe something at field level.
I really can't understand how this is still not available.
Thanks in advance.
This is level of security granularity is not available these days.
What you can do is make an integration with another system like sharepoint where you expose the fields you want. You can use the TFS Integration Platform for this .
Related
I use VSTS/TFS for work and side projects and I wanted to setup a trigger/rule that would automatically move stories into a certain iteration when I move them from "New" to "Approved" or whatever column is associated with an active state. I know how to change the iteration manually but it would be way easier if there was a way to say something like this psuedocode:
if (workItem.State == "Active") {MoveToIterationActiveForTodaysDate();}
Ideally too, if this isn't too picky, I would like it to only run on initial move so I can reassign to a different iteration later if I wanted to.
If anyone has an easier way to do this too that accomplishes the same thing (moving items to an iteration without having to manually activate the story and move it to the desired iteration) that would work as well. I'm still figuring out the ideal way to manage VSTS/TFS. Thanks in advance
Using VSTS is able to customizable work item rules.
Whether it be automatically setting the value of certain work item
fields or defining the behavior of those fields in specific states,
project admins can now use rules to automate the behavior of work item
fields and ease the burden on their teams.
More details please refer this tutorial: Add a rule to a work item type
However, it works with fields in the work item, not able to move work item to different iteration or area directly.
There is no out of box feature could achieve your requirement with TFS and VSTS for now. You may have to customize TFS events/actions to achieve the same feature as right click the work item--select move iteration--choose iteration.
Moreover, you could also use some 3-rd party extensions/tools such as Giulio
suggested TFS Aggregator.
As of today, there is no built-in automation, so the community wrote some tools that react at TFS/VSTS events and run scripts.
I can suggest TFS Aggregator which is used by many organization throughout the world: I am one of the core contributor.
We use TFS2013 on premise. A request came up that when using Web Access, some members with Stakeholder access should only have limited rights when opening work items.
They should be able to edit Description, Acceptance Criteria, etc fields, but others should be read-only, such as Iteration, State, etc.
The only option I saw was about tags Create tag definition option under
Security >> Permissions, but that's not enough for me.
One idea was Customizing a process template, but this seems to be thin ice as our team doesn't have any experience with it and the things to avoid list is quite long.
The best workaround approach so far is to reference the TFS ClientLibrary from Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\ReferenceAssemblies\v2.0\ and create a custom website which implements only the required features (for example when opening a work item, State would be a Label instead of a DropDownList).
The drawback of this solution is that it would keep the whole WebAccess portal hidden, including its nice features.
So my question in short: is there a way to make certain fields read-only on the work item form for stakeholder members?
UPDATE
Eventually I went towards Template Customization using TFS Power Tools 2013. Now I have to following problem:
Applying rules for certain fields work just fine, but in case the field type is TreePath, saving the template gives the following error
TF26062: Rule '< READONLY for="[Global]\Stakeholders" />' is not
supported for the field 'System.AreaPath'.
There were validation errors. Continuing to save may cause the file to
become unloadable, do you want to continue?
According to this answer from 2009: "there are some particular fields which can't be applied rules for"
Any suggestions how to go on?
You can choose the work item types to make some fields read only.
You will never need to be careful to not mark field read only that are needed for adding items. That would include area and iteration. Use witadmin.exe to export the desired work item and add read only clauses only for those in the stakeholder group.
You would be better with a permissive model. Allow everything and tell them what bout to change. Then have an alert for changes to those fields by stakeholders.
We're about to implement TFS 2012 and I've been having some fun customizing some work items to aid us in our reporting. One issue we have is our reporting based on clients.
Our Product Backlog Items keep our requirements, however, we need to report our requirements per client (government regulations). Some requirements will affect all clients, some will only reflect certain ones. I've been able to add a global list of clients along with a multi-select option and that part is working great.
The issue is we need to also note the requirement number for each selected client. I know I can go in and add a field for each 'Client Requirement', but as that list gets bigger, that screen will be insanely huge.
Does anybody know of such a way to implement something of the sort?
One option would be to create a custom Work Item Type for Clients. Then link your PBI's to the appropriate client WI's. When you create a link you can enter a link comment also which you could use to capture the client-specific requirement number.
I would create a custom "Client Requirement" work item that has the list of clients to select and includes a field for Client ID. You can then either use the related link type or create your own, maybe "Implements \ Implemented By" so that you can create a Reporting Services report that pulls the ID's
is there a way to hide the content of a field based on a role?
I thought about creating a serverside plugin which empties the field if the user does not have permission to view the field and repopulate it on save. But I don't know how to do this, I did not find any event which I could use. Any idea?
My first intent was to use the EMPTY rule but this really clears the content and does not repopulate it. Also the READONLY rule is not acceptable for us. Do you have any idea?
I know this was already requested http://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/2088177-add-ability-to-hide-mask-fields-in-a-work-item-bas but I need the functionality now.
I also thought about creating a workitem where the hidden fields are stored in and linking it to the other work item but this is not the solution I want ...
The only way to do this is by creating a custom work item control. That control can then only display the contents of the value if the user has the correct permissions. What it does not prevent though is to see/update the data via other tools like Excel, Work Item Query or Bulk Update.
As the suggestion on User Voice suggests, it is not possible today in TFS. So please vote and make sure the Team Foundation Server team knows it is high priority for a lot of our customers.
Ewald Hofman (Program Manager, Team Foundation Server)
In VS 2013 when u use the Empty Rule, the field disappear! You can see that in Scrum Template when you change de WIT state to Done the Remaining Work field are hidden
We're using team system to control our developement (product backlog items, sprint backlog items etc). It's a pretty nice tool but we wanted to allow other users to be able add bugs and new feature suggestions WITHOUT letting them mess with the actual development bits.
I can set these guys up so they add the work items they need but I can't see a way to block access to the bits I don't want them to edit/view. Has anyone else seen this? Has anyone found a solution?
Are you using TFS 2010? If so, you can simply add them to the Work Item View Only Users group. This will grant them access to create new work items and to view/edit any work items they've created (but not others). Check out this link for instructions.