Case sensitivity of the same person name should not be allowed

[cleowenxuan]

As mentioned in the textbook, different cases of the same word (eg: "John Doe" and "john Doe") is unlikely to mean different people. The app should at least give a warning to this kind of cases, since it might be a good chance that it is a typo.

[soc-pe-bot]

Team's Response

No details provided by team.

The 'Original' Bug

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

No handling of highly possible duplicate persons

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.

---

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

Their Response to the 'Original' Bug

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

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 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 response Team chose [`response.NotInScope`] - [x] I disagree **Reason for disagreement:** In the CS2103T TextBook, it was explicitly mentioned that a bug that relates to a duplicate person is not trivial. Since there is no warning for such near-match cases for the users to make the final decision and there is no clear mention of whether it has a duplicate detection feature, this bug is considered to be a Feature Flaw and is invalid to be NotInScope. 

---