No handling of highly possible duplicate persons

[bennyLCK]

add n/Amanda Tan p/87654321 t/COVID was run to first add a person, next, add n/Amanda Tan p/87654321 was run (additional whitespace between words).

The outcome was that the second person could be added successfully below without warning or prevention.

There was no clear mention on whether duplication detection was done for names in the UG, and because of this, whenever a user forgets that he had previously added a person already, he might add duplicate entries without realizing sometimes.

After running the add n/Amanda Tan p/87654321 t/COVID and seeing the result below,

The duplication check is done whereby entries are treated as duplicates likely only if all fields present are equal, I feel that this may be a feature flaw and potentially problematic since a user is not likely to type in exactly same commands multiple times and two entries with same person name or even phone number by itself should indicate a unique identity.

[nus-pe-bot]

Team's Response

It is indeed possible for two people to share the same name (there are at least five Jun Jie’s in NUS at present), and it is also possible for two contacts to have the same phone number (a parent and a child). Hence, checking equality of contacts by checking equality of both name and phone number is an intended behavior and not a bug. We think the duplicate rate resulting from typos such as this is sufficiently negligible that we will not implement anything extra to resolve such “highly possible duplicate persons”.

Items for the Tester to Verify

:question: Issue response

Team chose [response.NotInScope]

• [x] I disagree

Reason for disagreement: Firstly, it was not mentioned in the UG explicitly on whether there were any duplication detection schemes for persons except perhaps this segment

which hints at the part "Hence, checking equality of contacts by checking equality of both name and phone number is an intended behavior and not a bug," mentioned in the team response which is possibly an "administrative purpose".

I believe that just this omission of an already existing duplication detection scheme for persons is sufficient to be deemed as a medium severity documentation bug as this piece of information is critical to the application's use. Furthermore, it cannot be overlooked under this clause in identifying documentation bugs as shown below since there was no prompt or prevention of possibly duplicate insertions in the application itself.

In addressing the team's response on 'We think the duplicate rate resulting from typos such as this is sufficiently negligible that we will not implement anything extra to resolve such “highly possible duplicate persons”', I would like to refer to the guidelines in the course website on determining feature flaws regarding duplication detection shown below.

Since persons with the exact same attributes, differing only by an additional whitespace between two name words as shown in my issue above is allowed to be inserted in the application, the user would be oblivious of such duplicate insertions and furthermore, since the duplication detection scheme is flawed to begin with (even this given example is treated as 'not duplicates'), the application does not prevent such duplication insertion attempts in any meaningful way by providing prompts to the user asking whether he is sure to perform such possibly duplicate insertions or to prevent it altogether.

Therefore, I believe that this issue should be in scope and classified as a severity.medium feature flaw since oblivious duplicate insertions of person entries may happen to most users who may have forgotten that they had previously inserted details regarding specific patients with respect to the target user "clinic clerks" who are not likely to remember all associations between patient names to physical entities who have visited the clinic and typed in their names with an extra whitespace between any two name words.

---

## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** With reference to the above explanation.

---