[almighty] How would the 'search' URLs look like for the ALM Search service ?
Todd Mancini
tmancini at redhat.com
Thu Oct 20 13:18:41 UTC 2016
So, replying to basically everything here and no one in particular.
1. User expectation (based upon years of Google) is that search 'just
works'. One box, I type in what i want, and I get it. No need to specify
fields, etc.
2. The ability to search particular fields is a nice-to-have for advanced
users, but generally goes unused even when available. (Happy to grab a
drink and talk at length on why I know this kind of stuff...long story...)
3. Let's not confuse Search with Filtering nor Querying.
3a. Search is when you type what you want into a search box and you get
it.
3b. Filtering is when I'm looking at stuff and I want to see less of it.
Generally interactive.
3c. Querying is essentially a+b, and normally queries can be saved for
repeat usage. Filtering post-query is also common. In general, queries are
used to populate a UI. For example, a Kanban board, a Product backlog, a
Sprint Backlog, a list of release blockers, etc. etc. These UIs are
generally driven by a query, and users should be able to have multiple
queries driving them.
What's more important to consider are the 'magic' variables that need to be
part of queries. Things like '@me' -- so, a query for "assignedTo=@me"
would return all items that are assigned to 'me', regardless of who runs
the query. @project, @organization, etc. Probably some form of current
date/time (@now, @month). Less easy to do are things like
@currentIteration, because there can be multiple, overlapping iterations,
but we should think about them.
On Thu, Oct 20, 2016 at 8:53 AM, Monica Granfield <mgranfie at redhat.com>
wrote:
>
>
> On Thu, Oct 20, 2016 at 3:23 AM, Shoubhik Bose <shbose at redhat.com> wrote:
>
>> Hi folks,
>>
>> Wanted to discuss how the /api/search URL(s) would look like.
>>
>> To set the scope of the discussion right, I must mention that in this
>> sprint we are working on supporting search on ID , URL and full text ( for
>> title and description only ) of a workitem.
>>
>
> ** Am curious what is driving the need for these attributes to search by?
> I would have thought that search by assigned to would be a top candidate as
> these three attributes all focus on the work item only. Can we replace
> string with Assignee, as to address this issue?
>
>>
>>
>>
>> 1. The ID search is currently only on workitems. ( But in future it
>> would be supported for other objects as well. Example, Users,etc. )
>>
>> To search by ID --
>>
>> /api/search/q*=id:4324*
>> This is going to look up the workitem table *only*.
>>
>>
>> 2.
>> To search by URL --
>>
>> /api/search/q*=url:http://demo.almighty.io/#/detail/71
>> <http://demo.almighty.io/#/detail/71>*
>>
>>
>>
>> 3.
>> Search by ID *AND* URL is not supported.
>> If a q=xxyzz contains both URL and ID, we only pickup the URL and
>> discard the rest.
>>
>> Example.
>> /api/search/q=*id:4324*+
>>
>> *url:http://demo.almighty.io/#/detail/71
>> <http://demo.almighty.io/#/detail/71> *is effectively
>>
>> /api/search/q=*url:http://demo.almighty.io/#/detail/71
>> <http://demo.almighty.io/#/detail/71>*
>>
>>
> Behaviorally if I typed in 731 http://..../......
>
> I would expect it to pick up the ID first, as it is first in order. I am
> also wondering about the fuzzy type ahead that Max mentioned and if any
> thought has been given around that?
>
>>
>> 1.
>>
>>
>> 2.
>> Free text search is supported only on workitem title and description
>>
>> /api/search/q:=*title:some title substring*+
>> *description:some description substring *
>>
>> 3.
>> The delimiter for multiple clauses ( we shall support "AND" now )
>> will be "+" . ( inspired from Github ) as already used above. We need to
>> consider situations where the string itself contains a "+" by escaping them
>> properly.
>>
>>
>> 4. if the search query contains a mix of ID, URL , title,description :
>> The order in which we are going to look for fields to make a decision
>> on the search is:
>>
>> 1. URL
>> 2. ID
>> 3. title and description ( for free text search )
>>
>>
>>
>>
>> Let me know your thoughts :)
>>
>>
>> -
>> Shoubhik
>>
>>
>>
>>
>> _______________________________________________
>> almighty-public mailing list
>> almighty-public at redhat.com
>> https://www.redhat.com/mailman/listinfo/almighty-public
>>
>>
>
> _______________________________________________
> almighty-public mailing list
> almighty-public at redhat.com
> https://www.redhat.com/mailman/listinfo/almighty-public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20161020/6f4df834/attachment.htm>
More information about the almighty-public
mailing list