Contact add names not case sensitive

[Evande1]

• allows addition of same person with lower case
• although mentioned names are case sensitive

Steps:

1. contact add n/John Doe p/98765432 e/johnd@example.com a/John street, block 123, 2. #01-01
2. contact add n/john doe p/98765432 e/johnd@example.com a/John #01-01

could be higher if the user accidentally adds the same person several times without knowing especially if they key in lower-case.

[nus-se-bot]

Team's Response

No details provided by team.

The 'Original' Bug

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

Duplicate detection for records Functionality Bug

Duplicate records with names are allowed, as seen in the example above, with no case sensitivity check done.

User might think that it is the same person while it is not.

---

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

Their Response to the 'Original' Bug

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

Severity is changed to low because duplicated contacts are not expected in regular usage.

Firstly, your average user is unlikely to have contacts with the same name. This means a large portion of the user base will not be affected by the absence of case-insensitive duplicate detection. This means this bug should only affect a minority of the user base.

Secondly, adding case-insensitive duplicate detection is restrictive in the case where a user does know multiple people with the same name. For example, a user knows 2 'Alex Yeoh's. When adding both to TaskBook, they can add one as 'Alex Yeoh' and another as a different capitalzation, such as 'alex yeoh' or 'alex Yeoh'. Having case-insensitive duplication detection would prevent the users from distinguishing the 2 without adding some other identifier, like a prefiix or different details.

Thirdly, even in the case of an accidental double entry, such as a user adding 'Alex Yeoh', forgetting they added them, then add 'ALex Yeoh' after, it only causes minor inconvenience at worst to correct this mistake. Users can use our undo command to undo it, or if from a different session, they can search using contact find and easily delete contacts that way.

Additional accidents after the first accidental repeat addition are far more likely to be malicious in intent to sabotage the application and as such qualify for extreme inputs. Even if a user does add 20 different Alex Yeohs by accident, as mentioned before, they can easily just delete all of them, no harm done. The data is still all there, and the app does not crash or become unusable. Either case is not considered as a bug under module guidelines, so more extreme cases that lead to bigger inconveniences should not be considered.

Additionally, we note that for the case with the aforementioned accidental double(or multiple) entry, it only becomes an issue if they had a typo when adding the same person. It is extremely unlikely that a user would intentionally add the same 'Alex Yeoh' twice but have different capitalizations since most people would add Alex Yeoh twice with proper noun capitalization. The only 2 situations where different capitalizations would happen is in the event of a typo, which should be rare, or deliberate sabotage, which is as mentioned before, not a bug.

For all of the reasons above, this bug only affects a small amount of the user base and is only expected to cause a minor inconvenience. More extreme examples do not qualify as valid instances of this bug under module guidelines. Therefore, this bug is low severity.

Finally, this bug is also not a functionality bug, but a feature flaw instead because we explicitly stated in our UG that names are case-sensitive, therefore, it is working as specified.

Items for the Tester to Verify

❓ 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]

---

❓ Issue type

Team chose [type.FeatureFlaw]
Originally [type.FunctionalityBug]

• I disagree

Reason for disagreement: [replace this with your explanation]

---

❓ Issue severity

Team chose [severity.Low]
Originally [severity.VeryLow]

• I disagree

Reason for disagreement: [replace this with your explanation]

---