We’re using RT::Extension::PriorityAsString to give “friendly” names to priorities in RT (so “Normal” and “Urgent” rather than just numbers). Underneath is still the number that can be escalated as before, so “Normal” might encompass priorities 0 to 49 for example. Folk like it.
One of our users has noticed a problem though: when you make a search with Priority as the first sorting field and Id as a second sorting field, the output looks odd, with the Id fields out of order. The reason is that under the hood RT is doing the right thing and generating a SQL statement with an “order by priority, id” clause but the priority field is just a number, not the strings covering a range of numbers. Unfortunately, as we have multiple real priority numbers inside the “Normal” category, we end up with an order such as:
2063, Normal
2172, Normal
2286, Normal
2525, Normal
2606, Normal
2727, Normal
2549, Normal
2924, Normal
2532, Normal
This is because the first six have a priority of 4 (which is Normal) whilst the last three have a priority of 6 (which is also Normal). SearchBuilder doesn’t understand this of course because it (and SQL underneath) are just working on the numbers, so lumps the first six results under priority 4 and the next three under priority 6, which is right (from its point of view). The 4 and 6 then get turned back in the string “Normal” by the extension when rendering the results.
Not sure how (if!) I’m going to be able to work round this, but I thought I’d flag it up for others using RT::Extension::PriorityAsString and having odd Priority based search results ordering.