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)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

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.
Target Milestone: --- → 1.0
Assignee: nobody → vadimk
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
(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 ago14 years ago
Resolution: --- → WONTFIX
(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.