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.
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?
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.”
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.
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?