Simple search result count discrepancy

Hi. I guess this is sort of a bug, if you happen to use a simple search
in this way:

Where RT has Queues 1-10, and User A owns 371 tickets spread across all
queues, 100 of which are in Queue 1.

  • Log in as User B, who has rights to see only Queue 1
  • Type ‘A’ in simple search to find tickets owned by User A

Results header says ‘Found 371 tickets’, where one might expect it to
say ‘Found 100 tickets’. The actual results are the 100 tickets in
Queue 1, which is normal, but the header says differently.

I suppose this might be one of those debatable wishy washy instances
where a config option might end the debate? Any opinions from the dev
department? Should I submit a bug report? I would gladly submit a
patch, but I’m not quite smart enough yet.

David Smithson
ActivSupport, Inc.
Your Flexible IT Partner
Microsoft Gold Partner – Small Business Specialist
http://www.activsupport.com
Director of Technical Services
Direct: (415) 869 2991
Technical Support Hotline: (415) 979 9285
CLICK HERE FOR ONLINE SUPPORT

Hi. I guess this is sort of a bug, if you happen to use a simple search
in this way:

Where RT has Queues 1-10, and User A owns 371 tickets spread across all
queues, 100 of which are in Queue 1.

  • Log in as User B, who has rights to see only Queue 1
  • Type ‘A’ in simple search to find tickets owned by User A

Results header says ‘Found 371 tickets’, where one might expect it to
say ‘Found 100 tickets’. The actual results are the 100 tickets in
Queue 1, which is normal, but the header says differently.

I suppose this might be one of those debatable wishy washy instances
where a config option might end the debate? Any opinions from the dev
department? Should I submit a bug report? I would gladly submit a
patch, but I’m not quite smart enough yet.

This comes up every few months. The problem you run into is the
horrible, horrible performance issue when checking per-ticket acls.

Forgive me, I’m a lamer ( old term picked up during Commodore Amiga
phase ). What do you mean when you say “performance issues”? To me
that suggests that there is some variable condition.

David SmithsonFrom: Jesse Vincent [mailto:jesse@bestpractical.com]
Sent: Monday, August 14, 2006 10:30 PM
To: David Smithson
Cc: rt-devel@lists.bestpractical.com
Subject: Re: [Rt-devel] simple search result count discrepancy

Hi. I guess this is sort of a bug, if you happen to use a simple
search
in this way:

Where RT has Queues 1-10, and User A owns 371 tickets spread across
all
queues, 100 of which are in Queue 1.

  • Log in as User B, who has rights to see only Queue 1
  • Type ‘A’ in simple search to find tickets owned by User A

Results header says ‘Found 371 tickets’, where one might expect it to
say ‘Found 100 tickets’. The actual results are the 100 tickets in
Queue 1, which is normal, but the header says differently.

I suppose this might be one of those debatable wishy washy instances
where a config option might end the debate? Any opinions from the dev
department? Should I submit a bug report? I would gladly submit a
patch, but I’m not quite smart enough yet.

This comes up every few months. The problem you run into is the
horrible, horrible performance issue when checking per-ticket acls.

I guess the problem here is that Results.html performs 2 queries, one to
count the number of tickets for the search and another to fetch the
results …
I modified my instance of RT to only do one query fetching the result
and count at the same time, which is more accurate and efficient … not
quite sure why it was n’t designed to do this in the first place, I am
sure there was a good reason …
Regards;
Roy

David Smithson wrote:

Hi Roy,

have you compare the performance of your query with the original one from
bps?

I’m also interesst in this patch to try in our “big” installation.

Mit freundlichen Gruessen / With kindest regards

Torsten Brumm

Kuehne + Nagel
Ferdinand Strasse 29-33
20095 Hamburg
Germany

Tel: +49 40 329 15 199
Fax: +49 40 329 15 500
Www: www.kuehne-nagel.com

You get wrong numbers, as now RT shows number of ALL tickets that
match condition, but without ACL checks. As I understand you count
only tickets on the page.

It’s very hard to build SQL query that searches by user’s conditions
and also applies ACL checks at once. RT does next thing: search by
conditions, count all tickets, fetches tickets and filters the list by
ACL.On 8/15/06, Roy El-Hames rfh@pipex.net wrote:

I guess the problem here is that Results.html performs 2 queries, one to
count the number of tickets for the search and another to fetch the
results …
I modified my instance of RT to only do one query fetching the result
and count at the same time, which is more accurate and efficient … not
quite sure why it was n’t designed to do this in the first place, I am
sure there was a good reason …
Regards;
Roy

David Smithson wrote:

Forgive me, I’m a lamer ( old term picked up during Commodore Amiga
phase ). What do you mean when you say “performance issues”? To me
that suggests that there is some variable condition.

David Smithson


-----Original Message-----
From: Jesse Vincent [mailto:jesse@bestpractical.com]
Sent: Monday, August 14, 2006 10:30 PM
To: David Smithson
Cc: rt-devel@lists.bestpractical.com
Subject: Re: [Rt-devel] simple search result count discrepancy

On Mon, Aug 14, 2006 at 10:27:51PM -0700, David Smithson wrote:

Hi. I guess this is sort of a bug, if you happen to use a simple

search

in this way:

Where RT has Queues 1-10, and User A owns 371 tickets spread across

all

queues, 100 of which are in Queue 1.

  • Log in as User B, who has rights to see only Queue 1
  • Type ‘A’ in simple search to find tickets owned by User A

Results header says ‘Found 371 tickets’, where one might expect it to
say ‘Found 100 tickets’. The actual results are the 100 tickets in
Queue 1, which is normal, but the header says differently.

I suppose this might be one of those debatable wishy washy instances
where a config option might end the debate? Any opinions from the dev
department? Should I submit a bug report? I would gladly submit a
patch, but I’m not quite smart enough yet.

This comes up every few months. The problem you run into is the
horrible, horrible performance issue when checking per-ticket acls.


List info: http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel


List info: http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel

Best regards, Ruslan.