Bug 1219557

Created attachment 1023677 [details]
screen-shot: sorting VMs by IP Address

I tested on 3.6: I don't have VMs with IP addresses, so I cannot fully test it, but it seems that the GUI is properly sending the relevant search backend queries upon sorting by IP address (see attachment 1023677 [details]). 
However I don't know if the backend is actually returning the proper results or not (since I happen to have only VMs without IPs). 

So there are a couple of possibilities:

(1) the backend is returning the proper results -> it means that this 3.5 bug is already fixed in 3.6 (and originally might have been either a frontend and/or a backend issue). 

  - or -

(2) the backend is not returning the proper results -> it may mean that there is a problem with the "VMs: sort by IP" search query.

do you have more than one IP for a vm?
do you see any error in the engine.log (please attach)
this might be duplicate of
Bug 1164235 - Sort VM by IP fails if more than one IP listed for any VM entry

ping

no response, and likely a duplicate of 
Bug 1164235 - Sort VM by IP fails if more than one IP listed for any VM entry

please re-open if needed

*** This bug has been marked as a duplicate of bug 1164235 ***

This also occurs under Templates when listing VMs, even if none of the listed VMs have multiple IP addresses

i have verified sorting by ip works (tried only with a single ip address)
both on latest 3.6 and 3.5.4
please note that vms sub-tab under templates main tab does not implement sorting, only in the vms main tab.

so no code change needed,
moving to qa for verification.

missing pm + qa ack.

The other bug was only fixed in 3.6, this issue is on 3.5. Adding flags to make sure master + 3.5 are tested.

VMs with IP address are always first when sorted by IP, they should be behind the ones without IP when sorted in ascending order.
Otherwise it's OK.

(In reply to Petr Matyáš from comment #10)
> VMs with IP address are always first when sorted by IP, they should be
> behind the ones without IP when sorted in ascending order.
> Otherwise it's OK.

which build is this tested on? 3.6?

vt16.1, this one is for 3.5

michal,
please clone this bug properly to 3.5.4/3.5.5 , as it has customer ticket,
we won't be able to add it to errata if it won't have the right flags.

(In reply to Petr Matyáš from comment #10)
> VMs with IP address are always first when sorted by IP, they should be
> behind the ones without IP when sorted in ascending order.
> Otherwise it's OK.

this is by design, all fields with nullable values are last when they are null:
(in SyntaxChecker):

// Forcing any sorting using DESC to show NULL values last (NULLS FIRST is the default)
String direction = (obj.getBody().equalsIgnoreCase("desc")) ? "DESC NULLS LAST" : obj.getBody();

so, returning BZ status to the prev one

Created attachment 1052316 [details]
Screenshots - sorting FQDN and description

Then there is inconsistency in webadmin sorting. For example sorting by host works as you wrote, but if you sort by uptime ASC, items without value are first and if you sort by uptime DESC, items without value are last. Then there is sorting FQDN and description which works just weird.

So if this is correct behaviour for IP sorting I can file new bugs for the other fields.

well, it depends if the empty value in DB is empty string or null. I agree there is an inconsistency - I'd open a bug to make the sorting of the fields with empty value consistent and discuss independently if we want the empty values to be always the last or not.

there was no code change anywhere, no need to include that in erratum or anything