search

ng-andre / pe

0 stars 0 forks source link

Overly strict search query #3

Open ng-andre opened 2 years ago

ng-andre commented 2 years ago

image.png

Although UG specifies that input for search with ID field should be exact, search should also return results for all IDs containing the query for user convenience. Behaviour is also inconsistent with search for other fields

Steps to reproduce: Using the search command, input a search query that is a substring of an existing ID

Expected output: The search command should return all IDs containing the search query, which is expected for most search functions

Actual output: No results found for the given search query

nus-se-bot commented 2 years ago

Team's Response

I do not think searching by exact ID strictly will be the functionality less useful. When a user searches by title, most likely he/she would have a rough picture of the name of the item, in that sense, a less strict search helps, as implemented in the app. When a user searches a book by ID, he/she should already have the exact ID and would desire to quickly locate the exact item by searching using ID, therefore, matching strictly serves its purpose.

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

Reason for disagreement: By matching ID strictly, this would be considered overzealous input validation. In the event where the user only remembers the first part of the ID, he/she will be unable to try and search for the item in the catalog.

Next, since as mentioned the IDs are case sensitive, this could also lead to unnecessary rejection of IDs, which can mislead users into thinking that the item with given ID does not exist.

Lastly, if the library chooses to catalog all books under the fiction genre as FICxxx, where xxx is a number tagged to the specific item, they will not be able to search for all books in that genre. Considering there is no additional genre field in the application, this would be disallowing the user to use this feature in a way that you did not consider as developers.

As mentioned by the developers in response to another bug report on ID duplicate validation for bug report #7 Duplicate IDs with extra leading zeros are accepted as valid input :

Primarily, the team feels that part of the responsibility should be on the user in terms of entering the IDs of items. The reduced amount of input validation was also an attempt by the team to maximise compatibility in terms of libraries with differing ID systems and naming conventions.

If the rejection response to #7 is to be accepted, rejecting this bug would be inconsistent with that philosophy of trying to maximise usability with differing ID systems and naming conventions.