Report/Query result re-ordering should support secondary sort field.

[mikejbrady@…]

You get a little of this when you select grouping and ordering. It's grouped by the primary ordering, then sorted within the group for the secondary ordering. However, with lots of tickets, it's nice to have two sort levels within a grouping.

My favorite implementation makes the current primary sort field into the secondary sort field when another column is clicked. Here's an example:

The subsequent row is the result of the click action on a given row.

Current				Action
Primary		Secondary		Click
Milestone	v			Owner
Owner	V	Milestone	v	Version
Version	v	Owner	v	Milestone
Milestone	v	Version	v	Milestone
Milestone	^	Version	v	Owner
Owner	v	Milestone	^	Owner
Owner	^	Milestone	^	...

You get the idea.

[Christian Boos]

Interesting. We'd need some kind of visual hint about what's the primary and what's the secondary sort field.

[anonymous]

I often see the up/down arrow on the primary sort field. However, I have never seen an indication of secondary sort field, even when the feature is in place. It just becomes a sort of incidental bonus feature that people figure out pretty quickly. It really becomes pretty obvious with use. I suppose you could use arrows with differing opacity, or some other visual cue if you so desired. However, I do not see it as necessary.

I saw one app that supported tertiary sort with this column click reordering metaphor, though that certainly seemed like overkill to me.

[Matthew Good]

Since the Query module keeps the results of the last query in the session it should be possible to do a stable-sort based on the previous results, in which case there's no limit to the number of levels of sorting.

[Christian Boos]

#8320 requested this as well, and discussed the syntax for query links that would allow this. Implementing only #8320 might be a good intermediate step?

[Christian Boos]

Milestone 1.0 deleted

[mpotter@…]

Once one has generalized to support a secondary sort order, I would think supporting more would be minor (save the UI hints which I feel can be ignored). Except we may want to limit the possibility of redundant and/or superfluousness sorts. To avoid these my I suggest:

• When user selects a new sort column.
  • If same as current head
    • Change head to be it's reverse.
  • Else if id or any other unique value column (possibly the time-date columns)
    • Empty the sort-order list and replace with just the selected column.
  • Else if selected column is in the sort list
    • Remove it's previous entry, and add a new entry to the head of the list.
  • Else it is a new column
    • Add it to the head of the list.