Hi again all!
I’m discovering lots of anomolies today - sorry - this is the second post…
I have created saved searches to show us various tickets outstanding
for one reason or another - in one example i get WAY more results
found (170) than displayed (more like 60)
i have 4 pages of results for this query - though some of the pages
only have 10 or so tickets listed…
what are these phantom tickets that are being found?
Here is the query I used :
Status != 'stalled’
AND LastUpdated < '-48 hours’
AND Created < '-48 hours’
AND Status != 'resolved’
AND Status != 'rejected’
AND Status != ‘deleted’
any thoughts?
Hi again all!
I’m discovering lots of anomolies today - sorry - this is the second post…
I have created saved searches to show us various tickets outstanding
for one reason or another - in one example i get WAY more results
found (170) than displayed (more like 60)
Because of how RT’s ACLs work, it would be very, very time consuming to
check them before giving you a count of tickets found. And having to
load up all 170 tickets to get an accurate count of the ones you can see
before telling you how many it found would likely really, really frustrate you.
I ran into the same problem a few months ago. It has to do with the
fact that the function that is counting the total number of tickets
found doesn’t take into account whether the user has permission to view
them, but the function that then displays those tickets does take that
into account. I made a kludgy hack for this, but since you’re doing a
perms scan twice, it will make your performance take between a 10 and
20% performance hit.
For prior history from the mailing list, go to
http://lists.bestpractical.com/search.html and search on “Bug when
returning count of tickets found” - the first three links are the
relevant ones, my initial find, my kludgy hack (I think I changed it
again after this, though), and Jesse’s response about why it’s done the
way that it is.
Eric Schultz
United Online