[Rt-devel] Field Qualification PATCH for DBIx::SearchBuilder and numerous other (hints) of patches to come.

[Jesse Vincent]

On Wed, May 04, 2005 at 12:12:14AM -0400, Dowling, Brian wrote:
> Hello Jesse, All!
> 
> While I was doing some development on RT I realized that I could not
> pass SQL function calls to SearchBuilder's OrderByCols and GroupByCols
> functions that had Function('somparam', fieldname) through to the DB.
> In doing this I realized that these two *Cols functions utilized very
> similar code that needed to be fixed up.  The attached patch creates an
> internal _qualifyField function that does this work.


Thanks! I'm going to tweak a bit before I apply. (Mostly naming stuff).

> I also found one other place where QualifiedFields was being blindly
> set, so I changed that to use this routine as well.  Note that I added
> an (currently unneeded by my code) QUALIFIED flag that could be passed
> through to this function.  It would avoid any qualification and utilize
> the FIELD param as passed by the caller.  

*nod* I'm not quite sure. I sort of feel like we should add it the first
time we need it. That make any sense?

> * I have added a "Group By Columns" selection box to the search
> interface.  It allows you to pick multiple columns that you wish to
> "Group" the results by.  It ends up producing results such as:

Very nice! I've wanted this for a long, long time.

> * I was confused by the "Tickets" heading and the "Query Builder" both
> bringing me to the same place.  "Tickets" used to show you the search
> results, but now there is a separate "Search Results" Tab -- after you
> are in "Tickets."  For now I removed the "Query Builder" link and
> changed "Tickets" heading to "Ticket Search."  I would like to find a
> way when there is a current search in the session to always display the
> "Search Results" entry, but I have not delved into this.  IMHO the
> search Builder, while much more flexible, is a bit ominous.  I am not
> sure if we should consider having "hidden" advanced options and provide
> a more basic search interface for the quick searches?

*nod* Have a look at what we're doing with the "Simple Search" in the
quebec branch. This is something else that would benefit a great deal
from AJAXy progressive searches ;)  I agree that having a more friendly
beginning/intermediate search is the right thing.
 
> * To support the above grouping, I made some changes to the
> AvailableColumns list, in 3.4.1 some of the columns appear with the same
> name, e.g. two "Created" fields.  I adjusted the ones that are absolute
> time to be labeled "X Time" and left the relative time names alone.

That's something that should already be fixed in 3.4.2 that we got out
today.

> * I added very basic media="print" Stylesheet support.  What it
> basically does is remove any UI content, such as the left menu or the
> topbar quick ticket creation stuff.  On the results page I also have a
> hidden (to the display) box that presents the QueryDetails, timestamp,
> Query etc, making the printouts more useful in that you know what it is
> showing and how to reproduce it later if need be.  This was written
> quickly and is fairly rudimentary, but it works.

Nice. I'd love to see it.

> * I also added some support functions to email address entry fields.
> E.g. if you start typing an email addresses into a box (currently min 3
> chars), it'll go back out to the server and do a search for matching
> usernames and show you a server-generated autocompletion drop-down.  It
> understands comma separated addresses, etc and will help you
> auto-complete each individual part.  It is capable of searching the
> fullname as well as the email address.  (Actually it could search on
> anything, helpdesks might like typing in phone extensions they see on
> caller ID for example.) 

I want it. Lots. 

> Yes, this is JavaScript based, and I know I am going to get an earful
> about this.

Not from me. My big thing about technologies like javascript is that
they not degrade the experience for folks who aren't using them.
(You'll see a bit of Javascript used to create combobox fields for RT
3.6)

> This patch was done in a fairly
> CleanlyCustomizeRT(tm) "Add on Module" sort of way, but there may be a
> couple of added callbacks added to other components to make this work
> fully as a Module.

I'd love to see how you did it. Have you seen the RT-KeyBindings
javascript addon I stuck up on CPAN? It's something that should really
get added to RT's core, but it will take a fair bit of work to walk
through the UI and add bindings everywhere ;)  

Best,

	Jesse