Local changes to help ticket searching

Greetings,

Here is a summary of some of the changes we’ve made to help users search tickets. If there is interest, I can submit feature requests or provide more details. (See also another approach at http://requesttracker.wikia.com/wiki/Full_Text_Search_Portlet )

We index our database and normally want to do a Content Search. One of our managers wanted to type “cats OR dogs” in the “Search…” box and get a list all tickets with either cats or dogs in the content. And he wanted each occurrence to be highlighted when a ticket is displayed. And he didn’t want to use the full Search/Build.html interface unless absolutely necessary. So I tinkered a bit.

  1. When viewing a listing of tickets from Search/Results.html, we show the query just above the list of tickets (similar to what is seen below a chart from Search/Chart.html). This is very useful when following a link from a dashboard or RT at a Glance when it might not be obvious exactly what was searched. Best Practical added more callbacks in Results.html (after v4.0.8), and we print the query from a callback. It might be nice to have a user option to display the query directly from Results.html. This might require some CSS adjustment for it to look reasonable in all browsers, especially if the query is long.

  2. When doing a Content Search, we highlight the matching text when the ticket is displayed. This required adding a few lines in Ticket/Elements/ShowMessageStanza to wrap a around the match and creating a CSS entry with a yellow background. No doubt I am doing this in a very inefficient and inelegant way, but this does not seem to slow down the ticket display.

  3. I wrote a modified version of Search/Simple.html. This is used as the action when one uses the “Search…” box, or if one chooses Simple Search from the menu. I did not want to touch RT::Search::Googleish, so there are some very ugly hacks to manipulate the query string before and after calling Googleish for some of the effects. Very ugly, and a bit specific for our site. Key features:

a) Content Search (instead of Subject) is on by default. [perhaps RT should do this in Build.html and Simple.html whenever the database is indexed].

b) AND, OR, and Parentheses can be used between search terms. AND is assumed.

c) Our users were not happy with the page displayed by the original Simple.html nor with the complexity of the full Search/Build.html. So as a compromise, I added a few arbitrary items:
a drop down box to pick a queue;
check boxes to choose inactive/active status;
a text box with autocompletion to pick a requestor’s email;
check boxes to choose to search on Subject or Content.
Regards,
Jim Berry

Hi Jim

  1. When viewing a listing of tickets from Search/Results.html, we show the query just above
    the list of tickets (similar to what is seen below a chart from Search/Chart.html). This is
    very useful when following a link from a dashboard or RT at a Glance when it might not be
    obvious exactly what was searched. Best Practical added more callbacks in Results.html (after
    v4.0.8), and we print the query from a callback. It might be nice to have a user option to
    display the query directly from Results.html. This might require some CSS adjustment for it
    to look reasonable in all browsers, especially if the query is long.

This is something we’ve talked about doing internally for a while.
I’d be interested in seeing a small implementation of it to consider
for core (might need to be for master not for 4.0-trunk). As you
note, making it look good/fit well on long queries is important and
challenging.

  1. When doing a Content Search, we highlight the matching text when the ticket is displayed.
    This required adding a few lines in Ticket/Elements/ShowMessageStanza to wrap a around
    the match and creating a CSS entry with a yellow background. No doubt I am doing this in a
    very inefficient and inelegant way, but this does not seem to slow down the ticket
    display.

My initial reaction was “performance” as you note, but it’d still be
interesting to see what you did to see if it can end up in core.

  1. I wrote a modified version of Search/Simple.html. This is used as the action when one uses
    a) Content Search (instead of Subject) is on by default. [perhaps RT should do this in
    Build.html and Simple.html whenever the database is indexed].

Simple search makes this easy to do these days on 4.0-trunk
Tom wrote up something on rt-users yesterday about how to override the
default search strategy

I’ve implemented ‘make it fulltext and Subject’ by default for
someone. We need to pull more examples in the core docs for that.

b) AND, OR, and Parentheses can be used between search terms. AND is assumed.

This might be harder to handle without your override of Googleish.

c) Our users were not happy with the page displayed by the original Simple.html nor with the
complexity of the full Search/Build.html. So as a compromise, I added a few arbitrary items:

  a drop down box to pick a queue;

  check boxes to choose inactive/active status;

  a text box with autocompletion to pick a requestor's email;

  check boxes to choose to search on Subject or Content.

We’ve discussed a middle-of-the-road page, but I’m not aware of any
real work towards it in core. It sounds like a frontend like this
could end up posting to Search/Simple.html pretty easily.
I bet this could end up as an extension without much core scaffolding
required.

-kevin

Hi Kevin

Hi Jim

  1. When doing a Content Search, we highlight the matching text when the ticket is displayed.
    This required adding a few lines in Ticket/Elements/ShowMessageStanza to wrap a around
    the match and creating a CSS entry with a yellow background. No doubt I am doing this in a
    very inefficient and inelegant way, but this does not seem to slow down the ticket
    display.

My initial reaction was “performance” as you note, but it’d still be interesting to see what you did to see if it can end up in core.

I’ve attached a diff for ShowMessageStanza. One of the performance issues is that the regexp is re-created for each attachment in a ticket. No doubt there is a better way to do this.

The CSS definition is tucked away in local/html/Callbacks/xxx/NoAuth/css/base/main.css/End

span.localhighlight {
color: #000000;
background-color: #FFFF00;
}

– Jim

ShowMessageStanza.diff (1.2 KB)

My initial reaction was “performance” as you note, but it’d still be interesting to see what
you did to see if it can end up in core.

I’ve attached a diff for ShowMessageStanza. One of the performance issues is that the regexp
is re-created for each attachment in a ticket. No doubt there is a better way to do this.

You could definitely calculate once in a higher callback, like
grabbing BeforeShowHistory in Display.html and BeforeActionList in
History.html and stuff it back into the session for caching (just be
careful, one of my internal mottos is ‘Caching is Hard’).

Also, $& is a bit of a performance hit, but not as bad as $’ or $` so
hopefully anything it does is dwarfed by wire transfer time or the
quote wrapping code.

Would you mind making a ticket that’s just “Here’s some code I’m using
that might make an interesting feature if someone made it a bit more
core-like”.

Thanks

-kevin

Would you mind making a ticket that’s just “Here’s some code I’m using
that might make an interesting feature if someone made it a bit more
core-like”.

For core, we may want to investigate having the database return the
position of matches. I know Pg can provide the data, and I assume
Oracle can as well. I don’t know about Sphinx.