It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×42,884
×12,011
×7,480

question asked: Jun 06 '17, 6:26 p.m.
question was seen: 2,173 times
last updated: Jun 08 '17, 1:50 a.m.

Related questions

Issue trying to query an Enumerated list attribute

0
Gary Woodward (20●3●13) | asked Jun 06 '17, 6:26 p.m.
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.

One answer

Most liked answers ↑|Newest answers|Oldest answers

1
permanent link
Donald Nong (14.5k●6●14) | answered 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.

Comments
Gary Woodward commented 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 commented 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 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.