Best way to check for bad links via the REST API?
https://SERVER:9443/jazz/oslc/workitems/WORKITEMID/rtc_cm:com.ibm.team.workitem.linktype.parentworkitem.children.xml
and look for error "CRJAZ0215E" in the result.
For EVERY work item. In addition, I have to do this for each of the following link types:
.parentworkitem.children
.parentworkitem.parent
.relatedworkitem.related
.textualReference.textuallyReferenced
.relatedartifact.relatedArtifact
.attachment.attachment
.copiedworkitem.copies
.copiedworkitem.copiedFrom
.duplicateworkitem.duplicates
.duplicateworkitem.duplicateOf
.blocksworkitem.blocks
.blocksworkitem.dependsOn
That's 12 queries each for 50,000 work items. Is there a faster way to do this via the REST API?
3 answers
Comments
That would reduce the number of links I need to check, but it would not by itself result in a list of work items containing bad links. I would need to export the query results and then have my program check that reduced list of work items. That could cut the time in half, but I'd still be using the same method to check the links. I might do that though if this takes excessively long, as it likely will.
Bad links are sometimes created when deleting work items. Sometimes a link to a deleted work item remains. I have not been able to track down the exact cause and it is rare, but it does happen. Bad links can cause a variety of issues.
understood.. thus the suggestion never to delete workitems..
I don't know Java, thus no Java API for me. I am using Delphi. :)
I have the app working. It's very slow. The good news is I don't have to run it often, just after after I do a bulk delete. We end up with way too many bogus work items not to delete them.
First, run this REST API command for each work item:
https://SERVER:PORT/jazz/service/com.ibm.team.workitem.common.internal.rest.IWorkItemRestService/workItemDTO2?id=WORKITEMID&includeAttributes=false&includeLinks=true&includeApprovals=false&includeHistory=false
Then parse the results.
<linkTypes></linkTypes> contains each link type
<displayName></displayName> within each link type is the name of the link type, such as "Parent".
multiple <linkDTOs></linkDTOs> within each link type are your individual links.
<comment></comment> within each linkDTOs is your link name. The link name will be different if the link is bad.
For example:
Good Link: "Epic 24766: Field length change LDAP_ID"
Bad Link: "24766: Field length change LDAP_ID"
The type of work item of the bad link is missing. You'll need to ignore some types of link types that are not work items, such as "Attachments" and "Included in Builds".
I have switched my application to use the new method. Also, the old method would not list the number of bad links of a particular type.
By the way, you would not believe the number of bad "Mentions" and "Mentioned By" links that you probably all have!
Comments
Well, some caveats with the simpler method. The work item type does not appear with the following work item link types:
Mentions / Mentioned By
Contributes To / Tracks
Affects Plan Item / Affected by Defect
I can see no way of differentiating between a good link and a bad link for those link types using this method. Since the Mentions and Mentioned By links are the most prevalent of bad links, this is a problem.
Unless I find a better method, I am using a hybrid approach. I make an API call for the whole list of links and then if a Modified By or a Modifies is found, it checks the textReference link of that work item as well. Thus the resulting excel export might look something like this:
"Mentions" has a "?" on Qty since the result of the API call is the same whether there are 2 or 10 bad textReference links.