[rt-devel] Local changes to help ticket searching

[Kevin Falcone]

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

>    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
http://www.gossamer-threads.com/lists/rt/users/114498#114498
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
-------------- 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>