FIND Feature does not account for the way diseases are inputted

[nus-se-script]

Steps to reproduce:

• As per the UG, I have first add a contact add ic/S0074567D n/John Doe g/M b/10-07-1999 p/98765432 e/johnd@example.com d/Penicillin|paracetamol i/Infectious Disease i/Genetic Disorders, then find d/paracetamol.

Expected:

• I was expecting to find all patients with paracetamol allergy, however, the above contact was not listed.

Actual:

• However, I got no patients listed instead.
• This is problematic as the lack of validation checks on the drug allergies is causing the find function to not work as expected. The find function can conduct a substring search instead which will produce the correct outcome.

Screenshots:

---

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

[raysonchia]

Team's Response

Thanks for pointing this out. There are multiple bugs in this bug report:

• lack of validation checks on the drug allergies
• find function can conduct a substring search instead

The result you encountered has little to do with the functionality of the find command but rather the drug allergy validation which has been acknowledged in issue #5249. According to the user guide, the result to not return the patient with drug allergy Penicillin|paracetamol with find d/paracetamol is the desired outcome.

The find behaviour that it only returns matching full words has been documented in the UG: Thus, not performing a substring search is the correct behaviour. This is somewhat a limitation, but a choice had to be made between convenience and efficiency, and the team chose to prioritise efficiency. Furthermore, this situation is only possible as the user has not followed the drug allergy format suggested in the user guide, example commands and sample data where when entering multiple drug allergies, they should be separated with | and spaces.

Drug allergy entry in UG:

As this is an issue caused by an error in user entry and not the functionality of find, we will be rejecting this bug.

Duplicate status (if any):

--