Bug 601354 - search suggestions do not respect other filter terms in the search expression
Summary: search suggestions do not respect other filter terms in the search expression
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: RHQ Project
Classification: Other
Component: Core UI
Version: 1.3.1
Hardware: All
OS: All
urgent
medium vote
Target Milestone: ---
: ---
Assignee: Joseph Marques
QA Contact: John Sanda
URL:
Whiteboard:
Depends On:
Blocks: jon24-search
TreeView+ depends on / blocked
 
Reported: 2010-06-07 18:41 UTC by Ian Springer
Modified: 2013-08-06 00:37 UTC (History)
4 users (show)

Fixed In Version: 2.4
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-08-12 16:47:35 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 613149 None None None Never

Internal Links: 613149

Description Ian Springer 2010-06-07 18:41:05 UTC
Ideally, the suggestions should only include names of Servers, since I am on the Servers tab and the actual results will be implicitly filtered by category=Server.

Some possible fixes/workarounds for this:

A) Add support to the autocompletion for filtering suggestions according to the other search terms.
B) Add one-off support for filtering suggestions by category if one of the search terms is category=XXX.
C) Get rid of the Platforms, Servers, and Services tabs altogether.
D) Show the category=Server search term explicitly to remind users results will be filtered as such.

Joe, did I miss any?

Comment 1 Joseph Marques 2010-06-07 19:17:24 UTC
This is most evident when navigating to, say, the Resources>Servers sub-tab of the inventory browser, and the auto-completion results provide suggestions for the names of services.

However, even if the user was on the Resources>All sub-tab, this could be seen if you typed "category=server name=", which would provide names suggestions but it would **not** filter by names of servers.

So, this feature request really entails being able to provide suggestions that are relevant to *all* known search filter information at that time.  Generally speaking, if the user has a search expression with N conjunctive terms (i.e., 1 and 2...N-1 and N), and if the user wants suggestions for the (N+1)st term, the auto-completion algorithm needs to filter the (N+1)st results by the other N terms in the conjunctive list.

A general solution to this problem needs to take into consideration the search expression can be arbitrarily complex with ANDs/ORs and arbitrarily nested with precedence operators, for instance: A and (B or (C and D) or (E and F)).  This general solution is what Ian was referring to with fix/workaround A.

-----

As for the other suggestions, I'll address them each in turn:

B -- This could be done for the simple case of "A and B and C" where one of the terms is a category filter, but things become more complicated for expressions like "A and (B or C)" because the category filter would only implicitly apply to some of the terms in the expression.  This conditional logic makes this one-off solution only *slightly* less difficult than the full/general solution.  Thus, if we decide this kind of solution is worth it, we might as well go for solution A instead.

C -- I'm definitely in favor of this.  The only reason we had sub-tabs to begin with was because the filter textbox used to be constrained to searching resources by name *only*.  This name-only search is also why we had type and plugin drop-down boxes.  But now that search allow you to filter by name, category, type, plugin, availability, connection properties, configuration properties, traits, recent alerts, etc...the need to have separate tabs is significantly mitigated.  

D -- If we want, we can gives users 3 saved searches out-of-the-box, one for each category.  This would be a very effective replacement for the tabs, as it would: 1) eliminate the need for sub-tabs on for the inventory browser, b) immediately show users that they can search their saved searches, and c) naturally teach them some of the search syntax.

Comment 2 Ian Springer 2010-06-07 20:31:52 UTC
+1 on C along with the out-of-box saved searches for the categories. 

As for A, although I think it would make the autocompletion more intuitive in most cases, one disadvantage of it would be that the user would not have the ability to play with the search terms as easily. For example, once they had typed "category=Server", they would no longer be able see the full inventory-wide autocompletion list for name= unless they deleted the category=Server term. That said, I think I'm still in favor of implementing A at some point post-3.0.

Comment 3 Charles Crouch 2010-06-08 03:25:49 UTC
We need to discuss the options and see if there is anything that can be implemented for GA

Comment 4 Charles Crouch 2010-07-09 20:18:29 UTC
Discussed more with Joseph and for me this issue boils down to the fact that right now we offer Text (name) based suggestions on Platform/Server/Service tabs which if you select one which doesn't match a corresponding Platform/Server/Service, will return zero results.

To avoid this for 2.4 we need another option:

E)  Add one-off support for filtering suggestions by category if you are searching from the service/server/platform tabs.

This should ensure that the only names we suggest will yield non-zero search results. As pointed out elsewhere in the comments this does not solve the whole problem since we won't filter advanced suggestions by the implicit category, e.g. go to the Servers tab and enter "type=" (without quotes) and you will be given suggestions for types of non-server resources, such as CPU. If you choose the CPU suggestion and submit that search, you will get zero results. The solution to this involves implementing option A, which should be considered after the release.

In the mean time we need a documentation FAQ entry along the lines of:
"I used a search term from the suggestion drop-down, but got no results. What happened?"

Where one of the answers would be describing the situation mentioned above with the type=CPU

Comment 5 Joseph Marques 2010-07-09 21:40:44 UTC
commit 0cefa02502c348f4007d6f0f3cef0186cb2b194c
Author: Joseph Marques <joseph@redhat.com>
Date:   Fri Jul 9 17:35:01 2010 -0400

BZ-601354: only offer resource/group suggestions specific to the active sub-tab (if any)
    
* this is a one-off fix for the next release only
* this solution needs to be replaced by a generic solution that will filter suggestions by all known contextual data (i.e., other completed search terms)

-----

note: this was implemented for both the resource browser (platform, server, service, or "none" filter) and the group browser (compatible, or mixed, or "none" filter)

Comment 6 Corey Welton 2010-07-22 19:29:41 UTC
Have tried 

* name=
* type=
* plugin=
* connection[<type>]=
* category=
* Quoted search
* unquoted search

...across all three tabs, "Platform", "Server", and "Service".

The only very minor issue i found has been outlined in bug #617336, which may turn out to be more philosophical than anything else.

QA Verified.

Comment 7 Corey Welton 2010-08-12 16:47:35 UTC
Mass-closure of verified bugs against JON.


Note You need to log in before you can comment on or make changes to this bug.