Bug 535327 (RHQ-2034)
| Summary: | sorting groups by children or descendents | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Other] RHQ Project | Reporter: | Lukas Krejci <lkrejci> | ||||||
| Component: | No Component | Assignee: | Charles Crouch <ccrouch> | ||||||
| Status: | CLOSED NOTABUG | QA Contact: | Jeff Weiss <jweiss> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | low | ||||||||
| Version: | 1.2 | CC: | cwelton, dajohnso, hbrock, mazz, whayutin | ||||||
| Target Milestone: | --- | Keywords: | SubBug | ||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| URL: | http://jira.rhq-project.org/browse/RHQ-2034 | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | 1.4 | Doc Type: | Bug Fix | ||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: |
r3856
|
|||||||
| Last Closed: | 2011-04-01 18:28:35 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 565628, 577853 | ||||||||
| Attachments: |
|
||||||||
|
Description
Lukas Krejci
2009-04-28 07:52:00 UTC
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%. Some history... 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. keyword: 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. |