Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

Issue trying to query an Enumerated list attribute

Questions
Tags
Users
Badges
Gary Woodward
(20●3●13) edited
Jun 06 '17, 6:31 p.m.

We are on RTC 6.0.2 iFix010. I am trying to query Request for Change (RFC) Work Item's type with an enumerated list, "multi-impact", attribute with the following options:

-- unassigned

-- yes

-- no

Both the Default Literal and the Unassigned Literal are "Unassigned".

When I query for RFC's that have the multi-impact attribute noted above that is unresolved I get inconsistent results. Below is the result of a query that queries for RFC's where the attribute is as follows:

unassigned = 66
yes = 46
no = 28
all three conditions = 140

When I remove the filter altogether = 2,223, (which returns the number of RFC's that are unresolved)

I originally thought it may have something to do with the attribute configuration. But no matter what I tried it didn't work.

Thanks in advance for any assistance you can offer.

0 votes

1 answer
5,099 views
0 votes

One answer

Permanent link
Donald Nong
(14.5k●6●14) Jun 06 '17, 8:51 p.m.

I cannot see any inconsistency based on my understanding. Although the attribute name is "multi-impact" and is of the type enumeration list, I believe it is in fact single-valued - it makes no sense to select more than one values given the literal labels. So the number of unresolved RFCs with such attribute adds up perfectly: 66+46+28=140.

The only bit appearing inconsistent is the number of unresolved RFCs is way larger than you may expect, but it can easily be explained - some RFCs just don't have such attributes and RFCs that are last updated before the "multi-impact" attribute was added to the work item type naturally fall into this category. If you pick an RFC that is not in the 140 that you can find, you should see that it does not have the "multi-impact" attribute - using an OSLC call to verify it as you can really tell in an editor.

1 vote

Comments
Gary Woodward
Jun 07 '17, 12:37 p.m.
Thanks for you response, Donald. All of your assumptions in your answer seem to be accurate except all of the RFC's do have the multi-impact attribute. However, the multi-impact attribute was recently added, and although a default value was not assigned, it defaults to unassigned. As noted before, if I query for RFC's that are unresolved and the multi-impact attribute = unassigned, it returns 66. But when I remove the multi-impact condition it returns 2,223 (basically, the number of RFC's that are unresolved). When I review the actual results, all the multi-impact attributes in every RFC are populated with the value "Unassigned", or "Yes", or "No". None are blank. Can you help me understand why they aren't included in the results when Unassigned is included in the query.

Donald Nong
Jun 08 '17, 1:50 a.m.
Having an "unassigned" value is different from having no value.  Since the attribute was recently added, unless you have used the "Check attribute usages in repository > Synchronize Attributes" feature in the Eclipse client, your old RFCs do not have this attribute at all. As I suggested earlier, please use a REST client to retrieve the XML content of a work item and double check. If you find two work items with the exact enumeration value "unassigned" and same state, but still one appears in your query result and the other doesn't, it will be case for IBM Support to investigate further.

Your answer

Register or log in 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.

Ask a question
Guidelines
FAQ
Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 12,146
× 7,624

Question asked: Jun 06 '17, 6:26 p.m.

Question was seen: 5,099 times

Last updated: Jun 08 '17, 1:50 a.m.

Confirmation Cancel Confirm