Queries ought to support less/great than for ordered values (i.e. priorities and severities)

[macke@…]

I.e. expand the [is|is not] operator set a bit.

[Christian Boos]

Similar to the request for ordering on dates (I can't find that ticket anymore, but it's not a duplicate anyway).

And no, it's not a trivial change…

The TicketQuery expressions should also support the common ordering operators (<, ⇐, ⇒, >).

[Marcus Lindblom <macke@…>]

Replying to cboos:

Similar to the request for ordering on dates (I can't find that ticket anymore, but it's not a duplicate anyway).

Right.

And no, it's not a trivial change…

Sorry, I meant priority. Shouldn't have touched that field.

The TicketQuery expressions should also support the common ordering operators (<, ⇐, ⇒, >).

Yup.

[Christian Boos]

#1943 was the ticket about ticket date range queries I was looking for this morning.

[Christian Boos]

(more precisely #4594, which was closed as a duplicate of #1943)

[Remy Blank]

Related to #7419, which suggests defining an order for ticket statuses.

[trancesilken@…]

The problem here is that the priority and severity and other such enum type of values are stored as text. Sorting them based on < > ⇐ ≥ is not an option unless one also compares against the ordering number which is stored in the enum table.

However, the ordering number does only reflect the ordering by which the individual items will be displayed in the drop down when editing an issue.

The information as to which priority has the highest priority and which has the lowest is simply not there, unless one wants to utilize the ordering field in the enum table for this. And by comparing the strings alphanumerically will not do the trick, unless you assign your priorities names such as "1" for the lowest priority, or "2", or "3" for the highest priority.

The same is true for the severity field.