Red Hat Bugzilla – Bug 535327
sorting groups by children or descendents
Last modified: 2015-02-01 18:25:20 EST
The sorting of groups by children or descendents seems a bit confusing.
On the attached screenshot for sorting in descending order by descendents you can see that:
First row has 31 unavailable descendents, second row has 3200 available and 22400 unavailable descendents, and the rest of the rows have no descendents.
The behaviour is the same when sorting by children.
What is the logic behind these results?
See if this is an easy fix, otherwise push to 1.4
Need rationale from dev on this for current behaviour.
Pushed to 1.4
Reopening - it's in dev's queue anyway, it doesn't need to be in needinfo state.
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-2034
Imported an attachment (id=368737)
Imported an attachment (id=368738)
(In reply to comment #2)
> Need rationale from dev on this for current behaviour.
This appears to be working properly. The sorting action is sorting on the average availability for each group. So the child column for 'test mixed group', where there are *only* 31 down resources, has an availability of 0%. For the 'sam group' child column, it's availability is 12.5% (25/(25+175)). The other groups, since they have no members, have null/unknown availability. So an ascending sort put them in the following order -- 0%, 12.5%, unknown. A descending sort would have put them in the opposite order -- unknown, 12.5%, 0%.
The original implementation of of this might have seemed a bit more intuitive, because we didn't separate out the UP count from the DOWN count. Instead, we only showed RED if they were all down, GREEN if they were all up, and YELLOW for everything in between. Empty groups were still shown as GRAY question mark icons.
When this enhancement was first implemented, I had used 2 explicit columns for each of the children and descendent collections. This allowed you to sort on the number of up resources or the number of down resources for the children and descendent separately. For reasons I can't remember anymore, Greg Hinkle didn't like this, and wanted a *single* sort column for the each collection, and thus we have the implementation that this issue was opened against.
If people don't like how it's working today, or if they don't think it's intuitive anymore that's fine. What would you suggest instead? I'm flexible.
Temporarily adding the keyword "SubBug" so we can be sure we have accounted for all the bugs.
new = Tracking + FutureFeature + SubBug
making sure we're not missing any bugs in rhq_triage
Jeff, I'm still willing to get how we display this information. Do we have suggestions on how this should work?
i'm closing this - we sort as best we can. I think it makes at least some sense :)
we can revisit at a later time if we think we need to do something better. At that time, we'll need to define that this "something better" would look like.