627569 - Offer a way to search within each management pane

Status: VERIFIED DUPLICATE of bug 650976

(Mozilla QA Graveyard :: MozTrap, enhancement, P1)

Description

[Aakash Desai [:aakashd]]

There is a basic search function for every management pane that allows the user to look for the available entries depending on the category selected and searched for. Requirements include the following:

* Search field that can take multiple, space-separated terms
* Ability to limit a search within a certain available column for each search within a management pane
* Listings area that updates depending on the search provided
* For searches that take longer than 1 second (i.e. acceptable amount of time),
some sort of throbber

Available Categories per Results Pane:
* Testcases: creation date, id, title, test suite, state and tag list
* Test Suite: creation date, id, title and created by
* Test Runs: Creation date, Id, Title, state, assignment and author
* Test Cycles: creation date, id, title, state
* Users: Username, Name, e-mail address, role and company

There are more drilled down concepts that aren't brought to light in this
initial bug report, but we just need a basic set of functions that are
available to all users for now.

Comment 1

[Carl Meyer (:carljm)]

Like search on results panes, for textual search to be useful we'd need a search call on the API side that isn't just exact-match-only.

For fields that are not freeform, a filtering interface may be more useful anyway.

Comment 2

[Cameron Dawson [:camd]]

A Pivotal Tracker story has been created for this Bug: http://www.pivotaltracker.com/story/show/12752479

Comment 3

[Cameron Dawson [:camd]]

Cameron Dawson added a comment in Pivotal Tracker:   
   
This is really handles by the filtering mechanism, I think.  Eric and Carl: do you agree?

Comment 4

[Cameron Dawson [:camd]]

Carl Meyer added a comment in Pivotal Tracker:   
   
We should talk about this. On the implementation side, doing arbitrary word searches on text fields (name, description) via the filtering interface would be quite a big task, because the filtering UI would require autocomplete of search words, which we'd have to entirely build on the client side, and figure out how to populate the autocomplete list and keep it up to date). It's possible, but that alone would be a good several weeks of work. (It would also get us much better search results.)

On the flip side, we can just leverage the platform's simple text search capabilities if we add a freeform text search box (or if we just interpret words typed in the filtering box that aren't otherwise recognized as a filter as text search words). We'd still need to figure out the "limit by field" requirement here, though I'm not 100% convinced of the need for that.

Comment 5

[Cameron Dawson [:camd]]

Eric Meyer added a comment in Pivotal Tracker:   
   
"or if we just interpret words typed in the filtering box that aren't otherwise recognized as a filter as text search words" is exactly what I was thinking. The autocomplete list should always show both the fixed-terms (such as "active") and whatever you are typing as a free-form 'keyword' search. That should be true even if you type the word "active", because there is some chance that you want to search for the word "active" within a title or description. The more common (or fixed) option can remain the default, but both options should exist.

Comment 6

[Cameron Dawson [:camd]]

Cameron Dawson added a comment in Pivotal Tracker:   
   
That sounds great!  Let's do THAT!

Comment 8

[Cameron Dawson [:camd]]

Cameron Dawson deleted the linked story in Pivotal Tracker

Comment 9

[Matt Brandt [:mbrandt]]

Bumping to verified duplicate