wamps-jp / pe

0 stars 0 forks source link

`find` command too restrictive with certain fields #8

Open wamps-jp opened 9 months ago

wamps-jp commented 9 months ago

When using the find command, certain fields (such as name, role, or department) will only be searched by full keyword. For example, searching find n/ber in the below example will yield no results, despite the entry "Bernice Yu" being quite noticeable in the list.

image.png

I believe this is more than a slight inconvenience for users, since when searching for an entry, they may either make typos in the command, or may not remember the full name or keyword (hence the fact that they are searching).

I think this is an important feature to have, and would recommend allowing for, if not imperfect or fuzzy search, at least partial matches for said fields (to match the id, email, and other fields that it does work with).

nus-pe-script commented 9 months ago

Team's Response

Thank you for your input. We acknowledge that there could be some inconvenience in finding employees names if the HR staff member does not know at least one complete word in their name. For example, for Alex Yeoh, the HR staff member have to know at least Alex or Yeoh to find Alex Yeoh. We have considered allowing for the find command to find all employees whose names contain the keyword. i.e. Finding Alex would return Alex Yeoh as well as Alexander Yeoh. However, we decided against it in the end because we felt that we would then be unable to only find Alex if we were not interested in Alexander. I think that in the future we can add a feature where we can add an additional flag to specify that we want all names that contain the keyword. For example something like: find c/ n/alex will return Alex and Alexander since both contain alex in their names. For now I think that this is not in scope since the user cannot attempt to use this missing feature.

Items for the Tester to Verify

:question: Issue response

Team chose [response.NotInScope]

Reason for disagreement: Employees will often not be referred to by their full names in daily business, yet their database entries will likely be their full name. As in, an employee named Alexander Yeoh will most likely be referred to as Alex.

However, given this implementation, searching find n/ Alex will not find Alexander Yeoh, as you have said. It is more impactful if you cannot find Alexander by searching Alex than if you find extraneous names such as Alexander or Alexa by searching Alex.

Having extra results in the search feature will not majorly hinder the performance of the find command, but having missing relevant results will.


## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** Searching by `find n/ nickname` and not finding an employee's full name is not a rare occurrence for the user. It is likely that the user will often try to find employees by a nickname or a partial search (given that the users favor CLI, which is meant to be efficient). Not being able to find the employees via this method will happen multiple times a day.