<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Hi Shoubik,</p>
<br>
<div class="moz-cite-prefix">On 10/20/2016 09:23 AM, Shoubhik Bose
wrote:<br>
</div>
<blockquote
cite="mid:CANSWONkMZNTutL+T9tLTonO3dCJRjzjTPMxcHh2Hyf+FLBd9sA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<ol>
<li>The ID search is currently only on workitems. ( But in
future it would be supported for other objects as well.
Example, Users,etc. )<br>
<br>
To search by ID --<br>
<br>
/api/search/q<b>=id:4324</b> <br>
This is going to look up the workitem table <b>only</b>.
<br>
</li>
</ol>
</div>
</div>
</blockquote>
<br>
<p>What is the reason we are not using the "filter" parameter on the
/api/workitems endpoint for searching? <br>
</p>
What are we searching for here? A prefix? A substring? If it's a
search for the full id, we can just go to /api/workitems/4324. No
need to search.<br>
<br>
<blockquote
cite="mid:CANSWONkMZNTutL+T9tLTonO3dCJRjzjTPMxcHh2Hyf+FLBd9sA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<ol>
<li>To search by URL --<br>
<br>
/api/search/q<b>=url:<a moz-do-not-send="true"
href="http://demo.almighty.io/#/detail/71">http://demo.almighty.io/#/detail/71</a></b>
<br>
</li>
</ol>
</div>
</div>
</blockquote>
The work item service has no idea how to parse front end URL's. The
front end needs to extract the work item id from this and use that
for linking.<br>
<br>
<blockquote
cite="mid:CANSWONkMZNTutL+T9tLTonO3dCJRjzjTPMxcHh2Hyf+FLBd9sA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<ol>
<li>Search by ID *AND* URL is not supported.<br>
If a q=xxyzz contains both URL and ID, we only pickup the
URL and discard the rest.<br>
<br>
Example.<br>
/api/search/q=<b>id:4324</b>+<b>url:<a
moz-do-not-send="true"
href="http://demo.almighty.io/#/detail/71">http://demo.almighty.io/#/detail/71</a><br>
<br>
</b>is effectively<br>
<br>
<b> </b>/api/search/q=<b>url:<a moz-do-not-send="true"
href="http://demo.almighty.io/#/detail/71">http://demo.almighty.io/#/detail/71</a><br>
</b></li>
</ol>
</div>
</div>
</blockquote>
I don't think we should ignore parameters. If the query is not in a
correct format, we should return an error.<br>
<blockquote
cite="mid:CANSWONkMZNTutL+T9tLTonO3dCJRjzjTPMxcHh2Hyf+FLBd9sA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<ol>
<li>Free text search is supported only on workitem title and
description<br>
<br>
/api/search/q:=<b>title:some title substring</b>+<b>description:some
description substring<br>
</b></li>
</ol>
</div>
</div>
</blockquote>
What does "free text search" mean? where title like "%some%" or
title like "%title%" or something else (like a google search)? If we
do something like a google search, we'll need to think about ranking
and limiting the number of results.<br>
<blockquote
cite="mid:CANSWONkMZNTutL+T9tLTonO3dCJRjzjTPMxcHh2Hyf+FLBd9sA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<ol>
<li>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.<br>
</li>
</ol>
</div>
</div>
</blockquote>
As these are url parameters, we'll also need to delimit them
somehow. Also, we don't only have text fields, how are we going to
extend the format to other operators (<, >, etc.)<br>
<blockquote
cite="mid:CANSWONkMZNTutL+T9tLTonO3dCJRjzjTPMxcHh2Hyf+FLBd9sA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>if the search query contains a mix of ID, URL ,
title,description :<br>
<ol>
<li>The order in which we are going to look for fields to
make a decision on the search is:<br>
<br>
1. URL<br>
2. ID <br>
3. title and description ( for free text search )<br>
</li>
</ol>
</div>
</div>
</blockquote>
What "decision" do you mean here? Are you thinking about ranking?<br>
<br>
/Thomas<br>
<br>
<br>
</body>
</html>