Second-level sort

Having just made the jump from RT2 to RT3, I’ve got some users who are
flushing out differences in behavior. One of them likes to look at her
queue sorted by owner, but then had gotten used to an automatic subsort by
ascending ticket number. RT3 gets the primary sort-by-owner right, but
then the tickets owned by any particular person are in a seemingly random
order.

Anyone know whether it’s possible to get subsorts, or even have it default
to ascending numeric order?

Adam

adam hirsch By the time their numbers had dwindled from 50
adam@baz.org to 8, the other dwarves began to suspect ‘Hungry.’

I think the default sort order is by ticket priority,
but if you select any queue you can choose the sort order
by clicking on headers

Mike Husband (m.husband@leadup.com.au) wrote:

I think the default sort order is by ticket priority,
but if you select any queue you can choose the sort order
by clicking on headers

Right, the issue is when one has it sorted by owner, and want to see the
tickets owned by a given person in chronological order… make sense?

i.e. if I’ve got the queue grouped by owner, and I’m looking at regis’
tickets, they’re in some weird, nondeterministic order:

27189 NETWORK: more fun with netflow new ops regis 0
regis@upyournose.com 4 months - 4 months 0
31037 Office users accessing Pluto open ops regis 0
rbouchard@upyournose.com 3 weeks - 3 weeks 0
31066 switch configuration open ops regis 50
mikem@upyournose.com 3 weeks - 2 weeks 0
23645 NETWORK: investigate gear open ops regis 10
regis@upyournose.com 7 months - 7 months 0
31352 NETWORK: what time is it? new ops regis 0
regis@upyournose.com 2 weeks - 12 days 0
31635 NETWORK: managability new ops regis 0
regis@upyournose.com 8 days - 8 days 0
31133 NETWORK: tracking performance open ops regis 0
regis@upyournose.com 3 weeks - 12 days 0
26046 NETWORK: verify failover new ops regis 30
regis@upyournose.com 5 months - 5 months 0

in RT2, they’d be grouped by owner, but then in numeric ticket order within
each person’s tickets.

Anyone else seen this?

Adam

Schmendiman: Remember, the shortest distance between two points is a foot and
a half. No pun intended.
Freddy: No pun achieved.
- Steve Martin, Picasso at the Lapin Agile adam@baz.org

Yes, this is due to the addition of a ‘UNIQUE’ in the SELECT call in the
more recent DBI::Searchbuilder’s. The resulting MySQL query returns data in
a different order - if you can even call it an order.
My solution was to use the newer “OrderByCols” feature. I copied
share/Elements/MyTickets to local/html and replaced the following line at
the bottom:

$MyTickets->OrderBy(FIELD => ‘Priority’, ORDER => ‘DESC’);

With

$MyTickets->OrderByCols((FIELD => ‘Priority’, ORDER => ‘DESC’), (FIELD =>
‘id’, ORDER => ‘ASC’));

This seems to bring it back into line with previous behavior.
You’d need to do the same with MyRequests and any other elements that
generate a listing.

-=| BenFrom: rt-users-bounces@lists.bestpractical.com

[mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Adam Hirsch
Sent: Thursday, March 04, 2004 9:23 AM
To: ‘RT users’
Subject: Re: [rt-users] second-level sort

Mike Husband (m.husband@leadup.com.au) wrote:

I think the default sort order is by ticket priority,
but if you select any queue you can choose the sort order
by clicking on headers

Right, the issue is when one has it sorted by owner, and want to see the
tickets owned by a given person in chronological order… make sense?

i.e. if I’ve got the queue grouped by owner, and I’m looking at regis’
tickets, they’re in some weird, nondeterministic order:

[snip]

in RT2, they’d be grouped by owner, but then in numeric ticket order within
each person’s tickets.

Anyone else seen this?

Adam

Schmendiman: Remember, the shortest distance between two points is a foot
and
a half. No pun intended.
Freddy: No pun achieved.
- Steve Martin, Picasso at the Lapin Agile
adam@baz.org
rt-users mailing list
rt-users@lists.bestpractical.com
http://lists.bestpractical.com/mailman/listinfo/rt-users

Have you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm

Yes, this is due to the addition of a ‘UNIQUE’ in the SELECT call in
the
more recent DBI::Searchbuilder’s. The resulting MySQL query returns
data in
a different order - if you can even call it an order.
My solution was to use the newer “OrderByCols” feature. I copied

well, no ordering is guaranteed unless you explicitly specify an ORDER
BY that you want. in Postgres 7.4, this may bite you too, since the
UNIQUE and GROUP BY implementations have changed, and they no longer
implicitly order by the UNIQUE or GROUPed element(s).