"find" function does not work according to UG - substrings not found

[nichee]

Input :"find jo"

Expected: Amy jones, John doe and John doe found Actual: None found

[nus-pe-bot]

Team's Response

Thank for raising this issue as this is a valid bug. However, as mentioned in issue 346 previously, this is a documentation bug on our part. This is because as can be seen from the command description, command format and the app error message itself, we intended for it to only search using keywords and not substring. As such this is a duplicate of issue 346 as fixing that bug in the user guide will fix this issue as well. (image attached below)

The 'Original' Bug

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

Adding various duplicate names to the person leads to find command not listing down the patients names

Upon adding a couple of patients with the same name but different NRIC.

using Da as the keyword for finding names.

I am met with listing of 0 persons.

This could be the user not knowing if the keyword means that it has to be "David" in this scenario, leading to a misinterpretation

---

_{[original: nus-cs2103-AY2324S2/pe-interim#460] [original labels: type.FunctionalityBug severity.Medium]}

Their Response to the 'Original' Bug

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

Thank you for raising this. We acknowledge this is an issue, however, this is just a typo in the user guide and not a functionality bug in our programme. The error message in the actual MediCLI system states that find: Finds all persons whose names contain any of the specified keywords (case-insensitive) and displays them as a list with index numbers. (Screenshot attached below). The line you referenced was a typo as the overall description of the command in the user guide also states that it only accepts keywords.

Screenshot:

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)

• [ ] I disagree

Reason for disagreement: [replace this with your explanation]

---

## :question: Issue type Team chose [`type.DocumentationBug`] Originally [`type.FunctionalityBug`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]

---

## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** I understand the team's reasoning that this is a documentation bug and not a functionality bug(still debatable though), however I do not think the position that this is a low severity bug is justified.  Firstly, this is not a bug that would occur in "very rare situations" - any user who reads the UG would reasonably be led to believe that the 'find' command would find substrings. Indeed, this bug was spotted by 2 testers - it can reasonably be inferred that this bug is not "very rare", and instead occurs over the course of regular use. Secondly, I would argue that this problem causes more than a "minor inconvenience" as per the description of severity "low". As a user, it would not be easy to deduce that this erroneous behavior is the intended behavior of the app - thus creating an inconvenience and confusion as the user is unable to identify if they are using the app wrongly, understand the UG improperly, etc.  The team mentions the "overall description of the command in the user guide also states that it only accepts keywords.", however this is not fully accurate. The UG states that it finds "Patient (s) or Doctor (s) whose details contain any of the given keywords." There is no implication that exclusively full keywords are accepted, and it can easily be argued that a patient's details can contain a given keyword(which is a substring of their full detail). This also applies to the error message in the actual MediCLI system - it vaguely states "finds all persons whose names contain any of the specified keywords". Again, the word "contain" does not exclude the possibility of substrings being found. For these reasons, it would be extremely difficult for a user to deduce the intended behaviour of the feature, causing more than a "minor inconvenience"

---