Description of problem: If I click on the VMs tab on the 'IP address' header, the sort is done as if it was a text field: 10.35.113.9 10.35.113.30 10.35.113.3 10.35.113.16 where one would expect the order to be: 10.35.113.30 10.35.113.16 10.35.113.9 10.35.113.3 Version-Release number of selected component (if applicable): sm62 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
I thought it was a bug. And Max reminded me that also the name sort is not done quite correctly. It should be done in 'natural' order (http://www.codinghorror.com/blog/2007/12/sorting-for-humans-natural-sort-order.html)
not sure if this should be fixed at UI level or search sort level
As far as I can see, the IP header is not clickable (anymore?) so the bug is irrelevant (or maybe just obsolete). Yaniv?
(In reply to comment #3) > As far as I can see, the IP header is not clickable (anymore?) so the bug is > irrelevant (or maybe just obsolete). Yaniv? There should be a bug that in the move from the old UI to the old one we've lost all sorting per headers :( Einav?
(In reply to comment #4) > (In reply to comment #3) > > As far as I can see, the IP header is not clickable (anymore?) so the bug is > > irrelevant (or maybe just obsolete). Yaniv? > > There should be a bug that in the move from the old UI to the old one we've > lost all sorting per headers :( > Einav? That's right - when solving bug 893999, need to keep this bug in mind -> putting bug 893999 as a blocker to this one.
(In reply to comment #2) > not sure if this should be fixed at UI level or search sort level as long as the UI sort and the backend sort are not "connected" - it should be fixed in both (assuming the search-language allows sorting according to ip-address), in order to prevent inconsistent behavior. worth considering consolidating the two, maybe in the context of blocking bug 893999.
I'm not sure this one should be closed yet?
Well, it's basically fixed. The bug blocking this is about to be fixed, while the backend sorting by IP had been fixed as part of Bug 895468. So whenever the blocker bug is fixed, this could be moved to ON_QA for verification, or alternatively forgotten :)
Sven, I was actually too quick to respond, you're right and this should be reopened - there's still a little wiring missing for this to work by clicking on the column header.
oVirt 3.5 has been released and should include the fix for this issue.
Hi, sorry if this is not the place. But in oVirt 3.5.1.1-1.fc20 when you click in the header "IP Address" the small arrow changes direction, but the rows aren't sorted, and if you try to refresh the webpage or you change to another category and then return to the vms view, there is no information (rows), only 3 square dots in a loop. Could possibly it be related to this bug?
@Nir: How did you verify this works? based on Comment 11 there still seems to be a bug? Was Liors missing "wiring" from comment 9 fixed?
No, feature was completely implemented but there's a regression in 3.5, see Bug 1164235 (due to another bug fix...).