Sort running and not-yet-run crawls first by default

[emma-sg]

Closes #2528, #2034

Doesn't quite do everything that #2528 does, but this is a good first step towards better workflow sorting.

Changes

Changes workflow sort order when sorting by Latest Crawl (lastRun — the default sorting method in Browsertrix's frontend), lastCrawlTime, and lastCrawlStartTime to show running crawls first, then not-yet-run workflows, then the rest of results.

• Handles null lastRun values in lastRun, lastCrawlTime, and lastCrawlStartTime sorts
• Adds temporary lastRunHelper field to sort un-run workflows first
• Sorts by crawl running status, helper field, then target field
• Removes helper field after sorting completes

Testing

1. With this branch deployed as your backend, look at the workflow list with the default sort order. Verify that running crawls are bubbled to the top, then workflows that haven't been run yet, then the rest of the workflows in the expected order.

Screenshots

No running crawls	Running crawl

[tw4l]

I find it a little confusing that the "Latest Crawl" sort order would sort workflows that have no crawls before those that do? Seems like the opposite of what should be the case.

I get wanting to increase visibility of workflows that haven't been run yet, but I wonder if there's a better way to do that without confusing our users (as we did before when we had a more complex sort logic that wasn't really explained by the sort option label)

[emma-sg]

Hm, would this same sort order but with a fallback to last update date work better for workflows without crawls maybe? That way newly created workflows would still show up at the top with the default sort order.

The alternative here is probably to change the default order to "last modified", I think?

[tw4l]

Hm, would this same sort order but with a fallback to last update date work better for workflows without crawls maybe? That way newly created workflows would still show up at the top with the default sort order.

Having fallback sort logic that isn't apparent from the sort label is how this tab started, and we moved away from it because users very clearly and repeatedly communicated that they didn't understand the logic and were confused by the sort results not matching what one would expect from the label applied (which I think was "Last updated" at the time, which is quite vague). So I'm hesitant to go back in that direction.

I think floating running crawls to the top for "Latest crawl" makes sense, because still-running crawls are very much the latest. By the label, workflows that haven't been run should then be at the very bottom of the list for "Latest crawl", so seeing the opposite of that would I think rightly be confusing to some folks.

The alternative here is probably to change the default order to "last modified", I think?

I think we could do this (will have its own trade-offs, namely running crawls not necessarily being at the top), or possibly just trust our users to reverse the sort order or pick a different sort option to see their un-run workflows?

Either way I kind of see the question of how to ensure visibility of un-run workflows in the list as different than what we had been talking about for #2034, which is basically just applying a bug fix for the default sort option returning data that is different than what one would expect. And at the risk of sounding like a broken record, I think trying to approach them together in this way might be recreating a former problem.

[emma-sg]

Gotcha, appreciate your insights. I'll remove the parts of this that move un-run workflows to the top, so it'll just affect running ones.