Open ng-andre opened 2 years ago
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.
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.
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