[almighty] How would the 'search' URLs look like for the ALM Search service ?

Thu Oct 20 14:47:42 UTC 2016

Hi Todd,

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

To be clear, the feature discussed here is not fully generic search -  
it is to have
enough search to support the 
https://github.com/almighty/almighty-core/issues/307 feature
around linking.

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

the system itself still need to search by fields though :)

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

Yes, these are called functions in jira and something to look at when we 
start doing more full search features.

Btw. are these idea covered somewhere in PDD yet ? I didn't find it on 
first glance.
We should get it in there imo.

Also, search would in broader almighty not just be workitems but also 
code, builds etc. Also something to think about once we get there.

/max

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

> _______________________________________________
> almighty-public mailing list
> almighty-public at redhat.com
> https://www.redhat.com/mailman/listinfo/almighty-public

/max
http://about.me/maxandersen