Dangling reference after deleting work items
![]()
Curious if there's a cleaner way for me to workaround this:
We just upgraded to RTC 3.0.1 (from 2.0.0.2) and some of my REST api scripts started failing with an error of { The XML request worked fine, and I knew that the JSON response returns more data (specifically, it returns work reference ids for links, while the XML just returns a URL to the collection that has the work item references), so I went with the hunch that one of the collections had something wrong, so I queried all 22,000 links for this particular data set and found that some of the work items had text saying "bug 1" or "defect 1" in the text, which had created a textual reference. Of course, when I tested the deleting of work items, I deleted work item 1. In other words, the query for https://DOMAIN:9443/jazz/oslc/workitems/_5ItlAGeaEeCnuZ_CTu7zgg/rtc_cm:com.ibm.team.workitem.linktype.textualReference.textuallyReferenced was trying to return a work item that no longer existed. So, I noticed that most of dangling references were due to people saying "bug 1," so I removed the alias for bug=>defect and then re-added the alias for bug=>defect. This seemed to clean up all the dangling references where "bug 1" was concerned. However, I had to go by hand to all the defects that had "defect 1" and change it to something like "defecto 1" and then back to "defect 1". I think this will work (still working on it), but it's frustrating and tedious. Is there a way for me to reforce the parsing of work items for textual references? Has this bug already been filed/noticed? |
2 answers
![]()
Actually, the thing about removing the 'bug' alias and putting it back didn't actually work. I was forced to go by hand and remove the "Bug 1" or "Defect 1" text, save, then re-add it. Very annoying.
|
![]() |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.