[rt-devel] Local changes to help ticket searching

Kevin Falcone falcone at bestpractical.com
Tue Feb 5 11:32:40 EST 2013

Hi Jim

On Mon, Feb 04, 2013 at 10:35:55PM +0000, Jim Berry wrote:
>    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

>    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 <span> 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.

>    3. 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 235 bytes
Desc: not available
URL: <http://lists.bestpractical.com/pipermail/rt-devel/attachments/20130205/6f4c227b/attachment.pgp>

More information about the rt-devel mailing list