Closed
Bug 659226
Opened 14 years ago
Closed 14 years ago
Multiple searches on text field don't work
Categories
(Mozilla QA :: Case Conductor-Platform, defect)
Mozilla QA
Case Conductor-Platform
Tracking
(Not tracked)
RESOLVED
WONTFIX
1.0
People
(Reporter: carljm, Assigned: vadimk)
Details
When searching on e.g. a numerical status field, doubling the querystring key results in an OR search; e.g. testCycleStatusId=2&testCycleStatusId=3 returns cycles with status of 2 or 3.
When searching a text field, like name, providing the key twice doesn't seem to AND or OR the two search terms; instead, it seems to always return zero results. Preferably, it would do OR, just like for other fields.
| Reporter | ||
Updated•14 years ago
|
Target Milestone: --- → 1.0
I can't reproduce this. My testing always returns OR results when name supplied multiple times.
Example:
Request:
https://localhost/tcm/services/v2/rest/testcases/?name=test%20case%201&name=test%20case%202
Result:
<ns1:searchResult xsi:type="ns1:searchResult"><ns1:testcases><ns1:testcase xsi:type="ns1:testcase"><ns1:companyId>9</ns1:companyId><ns1:companyLocator xsi:type="ns1:ResourceLocator" id="9" url="https://localhost/tcm/services/v2/rest/companies/9"/><ns1:maxAttachmentSizeInMbytes>10</ns1:maxAttachmentSizeInMbytes><ns1:maxNumberOfAttachments>5</ns1:maxNumberOfAttachments><ns1:name>test case 1</ns1:name><ns1:productId>1</ns1:productId><ns1:productLocator xsi:type="ns1:ResourceLocator" id="1" url="https://localhost/tcm/services/v2/rest/products/1"/><ns1:resourceIdentity xsi:type="ns1:ResourceIdentity" id="1" url="https://localhost/tcm/services/v2/rest/testcases/1" version="0"/><ns1:testCycleId xsi:nil="true"/><ns1:testCycleLocator xsi:nil="true"/><ns1:timeline xsi:type="ns1:Timeline" createDate="2011-01-13T15:45:53-05:00" createdBy="1" lastChangeDate="2011-01-13T15:45:53-05:00" lastChangedBy="1"/></ns1:testcase><ns1:testcase xsi:type="ns1:testcase"><ns1:companyId>9</ns1:companyId><ns1:companyLocator xsi:type="ns1:ResourceLocator" id="9" url="https://localhost/tcm/services/v2/rest/companies/9"/><ns1:maxAttachmentSizeInMbytes>222</ns1:maxAttachmentSizeInMbytes><ns1:maxNumberOfAttachments>22</ns1:maxNumberOfAttachments><ns1:name>test case 2</ns1:name><ns1:productId>1</ns1:productId><ns1:productLocator xsi:type="ns1:ResourceLocator" id="1" url="https://localhost/tcm/services/v2/rest/products/1"/><ns1:resourceIdentity xsi:type="ns1:ResourceIdentity" id="2" url="https://localhost/tcm/services/v2/rest/testcases/2" version="0"/><ns1:testCycleId xsi:nil="true"/><ns1:testCycleLocator xsi:nil="true"/><ns1:timeline xsi:type="ns1:Timeline" createDate="2011-01-13T15:45:53-05:00" createdBy="1" lastChangeDate="2011-01-13T15:45:53-05:00" lastChangedBy="1"/></ns1:testcase></ns1:testcases><ns1:totalResults>2</ns1:totalResults></ns1:searchResult>
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → INVALID
| Reporter | ||
Comment 2•14 years ago
|
||
(In reply to comment #1)
> I can't reproduce this. My testing always returns OR results when name
> supplied multiple times.
> Example:
>
> Request:
> https://localhost/tcm/services/v2/rest/testcases/
> ?name=test%20case%201&name=test%20case%202
Ah, thanks for pushing to get it narrowed down. Bug only shows up if a provided value has % wildcard in it - any value with % wildcard contributes no results to ORed result.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
You can't have it both ways, meaning you either have a LIKE operator for a single text field or IN operator for multiple fields. There is no way combine partial search with a list search. UI application should provide correct wild cards depending on type of search...
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → WONTFIX
| Reporter | ||
Comment 4•14 years ago
|
||
(In reply to comment #3)
> You can't have it both ways, meaning you either have a LIKE operator for a
> single text field or IN operator for multiple fields. There is no way
> combine partial search with a list search.
Certainly there is a way to combine partial search with list search, in SQL: (name LIKE "blah%") OR (name LIKE "foo%").
If it's not feasible to implement this in the platform, we'll explore alternatives in the UI.
Yes, it's not the way our standard searches work and I don't envision changing it any time soon...
You need to log in
before you can comment on or make changes to this bug.
Description
•