Hi Bryn Mawr,

Can you tell me what filter you applied? I'll see if I can recreate the problem.
Thanks

@Bryn Mawr

That's strange. When I apply a filter and sort the 'return time' column, I get the rows correctly sorted by return time.
So I can't seem to recreate the issue.

Just to clarify, the 'return time' column has 'In Progress' showing up? Or is it just a blank value?

[zuhaib - please excuse the intrusion...]

Bryn Mawr,

As a user who got fed up with this a while back and found a possible work-around...

An experiment you might try: load your results page and make your device and/or project selection(s) but tell it to fetch as many results as possible rather than the default 25. Let it fetch the results without specifying a sort order (it seems to default to date sent, descending)...

Now specify a sort order and see what happens! In my case it made a big difference...

As far as I can tell from using Firefox to watch network traffic, sorting is done by the JavaScript working through the JSON files it fetches on a query - certainly, I can flip which columns I'm sorting on without it accessing the server, and although it might set the window back to 25 tasks it seems to sort on the data it fetched. (This may not apply if you open up your window to have more items than you originally requested, so I always ask for more than it is likely to find - 1000 without any filters at all, 250 or 500 if selecting for a device or a project!)

Even if that does resolve the issue it is not really a permanent solution - after all, it involves the user recognizing the problem and acting on it, which doesn't help folks who would probably never visit the forums... However, amongst the possible generic fixes WCG might try would be to fetch more results than the user appears to ask for, whilst maintaining the user's requested list size (which might need to be a configurable option as in "For results pages, fetch at most N results at once", so it starts to get messy!) The alternative of going back to the server and re-fetching the data every time a sort order is altered is probably not server-friendly, and would certainly make the results pages less responsive!

Good luck!

Cheers - Al.

Quoting Bryn Mawr...

That can be read in more than one way, so I'm unsure whether you tried my experiment or not. Hence, I decided to do another controlled test (using Firefox), paying particular attention to network traffic, in case I was hallucinating :-)

I started by selecting Open Pandemics and applying the filter - the web site returned a JSON file with 361 items in it. The display limit was set to 25, as I used to increase that once I'd got the filter engaged, and that was done after the first load (to get the filter into the URL, which I had assumed was a critical stage...) This behaviour appears to be what I'd wished for in my previous post - I wonder how long it's been doing that for!

Given the large fetch I decided not to increase the display limit and refresh :-) -- as it turns out, it probably wouldn't have refreshed anyway...

I tried various sorts orders and changes of display limit, and in each case, whilst the URL displayed by the browser changed to reflect the new request, the JS code seemed to recognize that there was no change in the underlying data request and simply invoked the login-status check if I changed "page"... Indeed, if the display limit was more than the amount of data it didn't even invoke the login-status URL. Note that I did not hit refresh during these tests (but see below).

As a result, I could navigate through the results 25 lines at a time if I wanted to, and order was retained. Switching what I sorted on didn't seem to cause a new data fetch either.

I then verified by switching to MCM1 (my other large use case...) That behaved the same. I tried getting all Pending Verification and Valid for all projects, and that behaved the same too.

Finally, I did something I don't usually do, which is to click on a link within a results page without routing the output to a different tab. When I eventually returned to the results page, the browser fetched the full result set again (but landed back on the correct page...) Behaviour is the same if I do hit refresh.

Now, some of this may be very recent; the behaviour (on my systems anyway) seems to be better than it was a few days ago...


No arguments with that! And I can't find a preference to alter the default anywhere in the profile (which would at least provide a way to avoid some of the irritation!)

However, if the "fetch it all" code isn't just something I'm seeing, this may be less of an issue for most folks - even I would be happy to do 25 (or 50) at a time if I could be sure it would get sorts right!

Cheers - Al.

Ah... thanks for the clarification! Strange, though, as I wasn't seeing that...

However, I have just managed to duplicate what you described. I had a results page that I hadn't accessed for about 14 hours (before the planned maintenance) and I just tried sorting it in various ways without an explicit refresh -- it showed exactly the behaviour you described! So I completely refreshed it and now it won't misbehave! So it looks as if the issue may not crop up (on my systems, that is!) if the data is reasonably current (and/or the session didn't need to refresh its security/session tokens).

By the way, the data I'm looking at (OPN1/OPNG) has a good spread of systems that return results in such a way that sorting on Return time results in significant scattering of Sent time values, so it isn't a case of correlation between the two times. (If I was only looking at one system that might be a concern.)

I'm going to leave that page alone for a few hours again, and if it starts to misbehave without a refresh I'll look at the network traffic to see if there's anything different going on!

[Edit: I have, indeed, revisited it - see next post...]

Thanks again for clarification and making me look again! I should never assume that because it's working when I test it that it's working all the time, and should've re-tested a little later...

Cheers - Al.

It's not beta-testing, it's "snagging"... :-) And I'd love to debug a "snag" without access to the code!