Welcome to the Jazz Community Forum
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
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?
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
{
"oslc_cm:message": "CRJAZ0215I The following record was not found in the database: com.ibm.team.workitem.common.internal.model.impl.WorkItemHandleImpl@568d568d (stateId: null, itemId: [UUID _PLZg4PZ3Ed6JmrepB6tnKQ], origin: <unset>, immutable: <unset>)",
"oslc_cm:status": 404
}
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?