search

Isabella-L / pe

0 stars 0 forks source link

Search Function #9

Open Isabella-L opened 3 years ago

Isabella-L commented 3 years ago

When searching for an ID, the ID needs to be exactly the same, if it is a "include" relation then there's no search result: Screenshot 2021-11-12 at 5.15.23 PM.png

However when it comes to item name, then an "include" relation shows the result:

Screenshot 2021-11-12 at 5.16.05 PM.png

Full List here:

Screenshot 2021-11-12 at 5.15.06 PM.png

nus-se-bot commented 3 years ago

Team's Response

The difference between searching by ID and searching by title is clearly stated in the UG. Searching by ID helps the user with the exact ID to quickly locate the exact item. Searching by title helps the user who has a rough idea of the name to search for the item

The 'Original' Bug

[The team marked this bug as a duplicate of the following bug]

Overly strict search query

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

[original: nus-cs2113-AY2122S1/pe-interim#1618] [original labels: type.FeatureFlaw severity.Medium]

Their Response to the 'Original' Bug

[This is the team's response to the above 'original' bug]

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 duplicate status

Team chose to mark this issue as a duplicate of another issue (as explained in the Team's response above)

Reason for disagreement: [replace this with your explanation]

:question: Issue response

Team chose [response.Rejected]

Reason for disagreement: I disagree that the requirement for exact ID for search does not hinder the feature. In other issues raised the team clarified that ID can take any characters not just numbers, then, what if the ID of a fiction collection is set to be fiction001 fiction002...? Book IDs in Singapore libraries sometimes have the same starting characters for books from the same author or authors with similar initials. In that case a "include" relation would be very necessary and taking it away hinders the search feature.

It would be more justifiable if the ID is number only, nonetheless, there are libraries that assign meanings to how the number is arranged.

I would say it is still a FeatureFlaw but the severity could be Lower.