It's all about the answers!

Ask a question

How to query RTC work item children for exact match of multiple attributes?

Volker Hoose (13114) | asked May 23 '13, 5:53 a.m.
edited Jul 03 '14, 4:54 a.m. by Ralph Schoon (63.3k33646)
I am using RTC 4.0.2 and have Epics with multiple Stories linked as children. I would like to run a query that lists all Epics with children that match multiple conditions per child:

[AND All must match]:
Type is Epic
Children > attribute_A is abc
Children > attribute_B is xyz

I am getting ambiguous results with the above query, because there might be a child matching the first condition (attribute_A is abc) and another child matching the second condition (attribute_B is xyz) while there is none that matches both conditions.
I would only be interested in listing Epics having at least one child that exactly matches both conditions.

Is there any way to build a query for this?

Any ideas would be appreciated,


Accepted answer

permanent link
Ralph Schoon (63.3k33646) | answered May 23 '13, 7:57 a.m.
edited May 23 '13, 7:58 a.m.
I think Lauren suggests the only possible way of doing it. The issue is, that although queries can follow relationships, the query language does not contain any means to express "For all children (condition on child)" or other complex conditions that would allow what you want, as far as I know. I once tried to create some queries that attempted this and I was never really able to accomplish it. I have seen some questions here in the forums around similar requirements and the same outcome.

I can't comment on BIRT.

It would be possible to use the API to run queries and to use the results returned for additional computation. Some example code can be found here: . You could run through result sets, access the resulting work items and do comparisons on the attributes. See and as well as other posts on that blog.

I am not sure if you could create a server extension that would do the same and be provided as query though. 
Volker Hoose selected this answer as the correct answer

5 other answers

permanent link
Lauren Hayward Schaefer (3.3k11727) | answered May 23 '13, 7:06 a.m.
Hi Volker,

A roundabout way to get the results you want is to query for a work item where attribute a is abc, where attribute b is xyz, and who has a parent of type epic.  Then you can edit the results to display the parent work item.  The problem with this is that the same epic might be listed more than once.

You might be able to create a query like this programmatically and then filter out the results so that each parent epic is only listed once.

permanent link
Volker Hoose (13114) | answered May 23 '13, 7:40 a.m.
Hi Lauren,

thanks for your quick response. Yes, I understand that using a query on the children (Stories) would lead to a precise evaluation of conditions (all stories that have attribute_A and attribute_B).

Unfortunately, I am interested in listing the parent (Epic) as a result of the query as I also need to display some attributes of the parent in the output (and I suppose there is no way to do this if the query returns Stories).

Regarding a programmatic solution, what would that involve? I have started looking at BIRT for building a report but this seemed rather difficult to accomplish.

Lauren Hayward Schaefer commented May 23 '13, 8:00 a.m.

Hi Volker,

I don't know of a way to display more about the epics using the query I described.

This link has more information on how to programmatically query work items:

I don't have experience with BIRT reports, so I'm not sure how difficult they are.

permanent link
Volker Hoose (13114) | answered May 23 '13, 9:35 a.m.
Ralph, thank you for sharing your experience. I will have a look at the links that you provided.

permanent link
Nate Decker (37814561) | answered Jul 02 '14, 10:17 a.m.

I've wanted to do the same thing in RTC, but reached the same conclusion that it isn't possible using the existing Query Builder. I improvised an API solution by leveraging REST, but this is something implemented outside of the tool.

My most recent idea is to create an Operation Participant server-side extension to populate an attribute in a work item based on my specific criteria. That works for 75% of the cases, but I haven't figured out the last step of it yet. It should be possible based on what I've read though.

Is there an enhancement request or defect or something we can link against to track this? I would like to be informed if IBM provides a feature that makes this possible.

Ralph Schoon commented Jul 03 '14, 4:40 a.m.

Nate, the only way to solve this I am aware of, would be to use the API to get the work items that have children and then iterate the result set and programmatic compare the attribute data. Don't hesitate to write a work item. I have written one a long time ago to be able to have exist, for all and comparable operators in queries. I think there are several things users would like to do with queries that are not possible today. We need to get that demand documented.

permanent link
Nate Decker (37814561) | answered Jul 03 '14, 10:18 a.m.

Ralph, I was going to submit an enhancement on this and had typed one up but then thought it would add more weight to it if I could find other forum postings. I found one that linked to an existing enhancement so I'll add that link here as well:

I intend to scour the forums a little bit more this morning and link any other forum postings I run across to that same enhancement.

Since you mentioned, "the only way to solve this I am aware of", I thought I would pitch my workaround to you and get your opinion on it as to the feasibility.

I am trying to provide a means for querying for Work Items where their children are all closed and they are not "blocked" by any dependent work items. To do this, I'm trying to create a follow up action (server-side java extension) to populate an attribute that will be added to all work items. The attribute will be a simple Boolean called "Blocked". Any time a work item is saved, the extension will examine the links and find out if 1) the current work item is blocked by any other work item and 2) if a change in the current work item's links has unblocked another previously blocked work item (e.g., by removing a parent->child link).

I've been able to achieve 1 successfully, but am having issues with 2 because I need to be able to compare the before and after links of the work item that is being changed. This doesn't seem to be working in my testing, but my impression is that this should work.

Anyway, for anyone else who wants to go the extension route, it seems like that should be a possible workaround. Set me straight if I'm off base here.

Your answer

Register or to post 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.