Is it possible to prevent a Child/Parent relationship on a bug? - tfs

We're using TFS 2017 on-premise, with an Agile template on our project.
If a user creates a bug and adds a link type of parent or child where the other work item is also a bug, it breaks the backlog board. You get a message telling you that the board ordering is broken, with a hyperlink on how to fix it.
Is there a way to remove Child and Parent from the Link Type drop-down list, where the source work item type is Bug?

No, we can not prevent or disable that. You may write a custom task with rest api to fix relations:
Find work items with relations: Wiql - Query By Wiql
Update work item: 1. Remove a link 2. Add a link

Related

When copying a work item in TFS can i control the link created between the items?

When I copy a work item in TFS (a bug for example), the link between the parent work item and the newly created item is always set to related.
I want to change the default link type created when copying since I want to use a custom link type i created.I couldn't find an answer anywhere.
We cannot control the link type when copying a work item.
However you can delete the related links, then add them again with selecting other link types (custom link type in your scenario) with TFS API.
Please refer to below articles for more information.
TFS API Cloning Work Items with Children
Create Link Between Work Item (Parent, Child etc…)
Creating a linked Workitem via the TFS API

TFS: Why do Issues appear on the Backlog?

We are using TFS 2015 together with the CMMI process template and I have just found out that Issues do appear on the backlog if they are a child of a Feature or a Requirement work item type. If the Issue is standalone (has not link to one of the two mentioned work item types) it is not visible on the backlog.
I guess that someone has made some hacks here in order to make this possible. Originally, only Epics, Features, Requirements, Tasks, and Bugs should appear on the backlog.
I have checked the Issue work item type definition as well as the processconfiguration.xml and the categories.xml which look quite ok from my point of view.
Are there any another places where one could define which work item types should be visible on the backlog?
Thanks a lot for giving support.
To add a WIT on backlog, the three files below need to updated:
WIT Definition
Categories Definition
ProcessConfiguration Definition
You can check the required changes on this link: Add work item types to backlogs and boards to see if these changes had been applied on your project. If yes, revert these changes, then the Issue should disappear from the backlog.
You should not use the "child" link to associate with Issues.
The Parent/Child link is used for the backlog and I would think that the Issues are appearing because of this.
Try changing the Parent/Child link to Related.

Resetting the Work Item Type history in the TFS WorkItem Query-Designer

Is it possible to reset the work item type history that is proposed to a user who creates a new WorkItem query?
We have some TeamProjects that went through two Process-Template customizations including localization and WorkItem form layout optimizations.
With TFS 2015 we're finally moving to the Agile process template. The problem is that somewhere the TFS stores the WorkItem-Types you have ever used and displays them in the WorkItem query designer.
The values in the Work Item Type are mixed both german and english and are picked from all of the past process templates the team project has ever been configured to use.
Is it possible to reset that list and if so, how?
The scope of the query editor is for all projects in a give collection. When you open the dropdowns, it thus shows all work item types in any of the projects in the collection.
In TFS 2015 we have added a checkbox to scope your query to the existing project. This checkbox is off by default because the majority of the queries run in the scope of a project. When the checkbox is unchecked, the dropdowns are limited to show only the states, fields and work item types that are in use by the existing project.
If you don't need these work item types and the work items, you can use witadmin destroywitd to destroys the work item types, after running the destroy command, the work item types will disappear from the drop-down. But please notice this will also destroy every work item of that type permanently without recovery.
witadmin destroywitd /collection:CollectionURL /p:Project /n:TypeName [/noprompt]

TFS custom wit - Getting list of changesets ids referenced to field

Im trying to create a custom TFS wit with a custom wit that is referenced to my changesets IDs.
For example, I need a field that contains a list of changesets IDs from my existing changesets in the TFS project.
Is it possible for making and customizing such field?
Thanks!
Yes, it is possible. You need to work with a custom work item control.
In the work item control, you can get a list of changesets via using TFS API (use the VersionControlServer.QueryHistory method). Also check this stackoverflow case for the details: TFS 2010: Getting list of changeset Ids
Please have a check on this link for the detailed information on how to create custom work item control: https://witcustomcontrols.codeplex.com/

Non-editable Work Item Type in TFS 2010

Is there any possibility to create a custom Work Item Type in TFS 2010 that is read-only after the first save?
We would like to implement a very simple code review solution based on a custom review work item associated to a changeset.
The idea is that after the work item is created, it can not be altered afterwards (not even by the original creator).
I've tried setting the System.ChangeDate to FROZEN but that isn't supported and unfortunately the first save is also a change, so setting it to EMPTY or READONLY doesn't work either.
Did you have a look at the community solution for code review for TFS 2010 http://teamreview.codeplex.com/
The most complete solution for Team System Code Reviews: a specific work item type and a Visual Studio add-in for a completely in IDE code review experience. TeamReview exploits the advantages of Team System and VSX to reduce waste and surface new business value from code reviews
HTH
Chees, Tarun
You might want to look at the work item type's workflow. You can make changes to fields in both the states and the transitions.
You could try to modify the transition from New to To Do (or whatever the first state is called for your WI).
In those transitions, you can freeze or make read-only the fields that you want to freeze.
Hope this helps,
Assaf.

Resources