Possible Bug?

Figured out what is causing this problem… the search query apparently
queries queues/tickets that the user cannot see but limits the display based
on the ACL? What this resulted in was 500+ tickets being displayed for the
user, but the user only had the ability to see a handful… thus they didn’t
always get a listing off all their allowed tickets. If you set the limit to
unlimited, the query takes a wack of time, but eventually will return the
desired results.

Wouldn’t it be better to make the search query only query the database for
the tickets that the user would have access to view?

Anyway, think this solution will suffice for us for the time being, just
thought I’d mention the oddity.

DerekFrom: “Derek Buttineau” derek@csolve.net
To: rt-users@lists.fsck.com
Sent: Wednesday, October 02, 2002 3:17 PM
Subject: Odd Search Problem

Just starting having an odd search problem with RT 2.0.14…

When we issue a search across multiple queues… say for example limiting
it
to user Nobody… it’s very inaccurate in what result is displayed.

IE if there’s 30 tickets owned by Nobody in the one queue… and 10 tickets
owned by Nobody in another … it might show 5!!

Not sure what caused it, tried turning on debugging, didn’t show me
anything… just just started happening after we crested Ticket ID 23000…

Any suggestions would be greatly appreciated.

Thanks,

Derek

We’ve encountered an issue that we don’t particularly like nor do we
know if it is engineered or a bug. It involves the searching of merged
tickets and is repeatable for all merged tickets in our database.

It would appear that after a merge it is impossible to find the ticket
merged INTO another based on the merged tickets id. To clarify:

Ticket #1 comes in.
Ticket #2 comes in and either is related to or is identical to ticket #1.
Ticket #2 is merged into ticket #1.
Searching for ticket #2 results in nothing instead of redirecting to
ticket #1 giving the impression that ticket #2 does not exist.

Is this a “feature”? If so how can I make it work the way I want it to?
Or is it just a bug?

Thanks,
Mathew Snyder

Mathew Snyder wrote:

We’ve encountered an issue that we don’t particularly like nor do we
know if it is engineered or a bug. It involves the searching of merged
tickets and is repeatable for all merged tickets in our database.

It would appear that after a merge it is impossible to find the ticket
merged INTO another based on the merged tickets id. To clarify:

Ticket #1 comes in.
Ticket #2 comes in and either is related to or is identical to ticket #1.
Ticket #2 is merged into ticket #1.
Searching for ticket #2 results in nothing instead of redirecting to
ticket #1 giving the impression that ticket #2 does not exist.

Is this a “feature”? If so how can I make it work the way I want it to?
Or is it just a bug?

This is a bug that the project maintainers have already announced.
Search the forum for “search in merged.”

Max

We’ve encountered an issue that we don’t particularly like nor do we
know if it is engineered or a bug. It involves the searching of merged
tickets and is repeatable for all merged tickets in our database.

It would appear that after a merge it is impossible to find the ticket
merged INTO another based on the merged tickets id. To clarify:

Ticket #1 comes in.
Ticket #2 comes in and either is related to or is identical to ticket #1.
Ticket #2 is merged into ticket #1.
Searching for ticket #2 results in nothing instead of redirecting to
ticket #1 giving the impression that ticket #2 does not exist.

Is this a “feature”? If so how can I make it work the way I want it to?
Or is it just a bug?

Mathew–

This has been discussed a bit in the last week, and I think it’s been
agreed upon that it is a bug. Refer to the following thread:

It should be the case that searching for the old ticket number will
get

you the new ticket.

This is what I expected.

I have an 3.6 installation from tarball. The installation is upgraded
from 3.0.12. The search problem appears in tickets which are created
before and after migration.

Ok, then yes, that sounds like a bug.

See the thread starting with:

http://lists.bestpractical.com/pipermail/rt-users/2006-July/040503.htmlOn 7/20/06, Mathew Snyder jokermjs19@comcast.net wrote:

We’ve encountered an issue that we don’t particularly like nor do we
know if it is engineered or a bug. It involves the searching of merged
tickets and is repeatable for all merged tickets in our database.

It would appear that after a merge it is impossible to find the ticket
merged INTO another based on the merged tickets id. To clarify:

Ticket #1 comes in.
Ticket #2 comes in and either is related to or is identical to ticket #1.
Ticket #2 is merged into ticket #1.
Searching for ticket #2 results in nothing instead of redirecting to
ticket #1 giving the impression that ticket #2 does not exist.

Is this a “feature”? If so how can I make it work the way I want it to?
Or is it just a bug?

Thanks,
Mathew Snyder


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

We’re hiring! Come hack Perl for Best Practical: http://bestpractical.com/about/jobs.html

Cristobal M. Palmer
UNC-CH SILS Student
TriLUG Vice Chair
cristobalpalmer@gmail.com
cmpalmer@ils.unc.edu
ils.unc.edu/~cmpalmer
"Television-free since 2003"

iank has trouble with English. his native language is Python
Yeah
I’m forced
To indent
My sentences

Thank you. I did do a brief search for EffectiveId and found nothing.
Next time I’ll be a bit more exhaustive before posting.

Thanks,
Mathew Snyder

Mathew Snyder wrote: