Adding duplicate names allowed if the names had different case sensitiveness

[yucongkoo]

Steps to reproduce: Add two entries with the same name but with different cases, an example is as follows:

• add n/Betsy Crowe p/92222222 e/betsycrowe@example.com a/Newgate Prison t/friends pmr/north

• add n/BeTsy Crowe p/92222222 e/betsycrowe@example.com a/Newgate Prison t/friends pmr/north

Result: The command executes successfully and both entries are added into the application.

Problematic behaviour:

The application has duplicate entry detections where they will disallow duplicate entries(entries with same names), Betsy Crowe and Betsy Crowe (with 2 spaces) is generally considered to be the same name, and hence should be detected as duplicate entries.

[soc-se-bot]

Team's Response

There might be a possibility that Betsy Crowe and BeTsy Crowe are 2 different people.

Items for the Tester to Verify

:question: Issue response

Team chose [response.NotInScope]

• [x] I disagree

Reason for disagreement: I think it is useful to quote the following section about duplicate detection from the course website:

Here is my stance on why I think that this should not be NotInScope:

• There is already a duplicate detection feature implemented, which is intended by the dev team(not just inherited from AB3) as they specifically stated that names should be unique in the UG as follows:

• However, there is no where in the UG/DG which states how they defined the uniqueness of names. Hence, going with the general assumption on names, it is not very logical for names with different case-sensitiveness to be considered different names. It is as the case described in the course website, where the users are led to believe that duplicates are detected but many duplicates can potentially go undetected.

• I believe that this is not actually a very hard-to-fix feature, it seems more like a flaw that was not carefully considered and missed by the developers team when deciding to include this duplicate detection feature.

On top of all the above arguments, I reported another bug that was regarding the case sensitiveness of tag, also related to duplicate detection, the bug can be found here. Despite that they did not mention that tags should be unique, they accepted the above bug, but decided to classify this particular bug as NotInScope? So from the developer's team perspective, does this mean that tag duplicate handling is more significant and important than name duplicate handling, even though the did not mentioned that tags should be unique? I find this contradicting and makes me even more harder to accept this as a NotInScope.

A side note regarding bug type: After spending more time reconsidering, I now think that this bug is considered a FeatureFlaw rather than a FunctionalityBug(that was originally reported), but the testers did not change the bug type, hence I am stating my change of decision here.

---

## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** Quoting the definition of different severity levels from the course website:  I do not think that this flaw will be occured only in **very rare** situations, rather, it is relatively easy to have different capitalisation when typing names, such as `Ryan` and `ryan` are often two ways to type the same name, which is quite common. Hence, I think it is more suitable for this flaw to fall under as an "occasional inconvenience" to the users, as they might be able to realise that they accidentally entered the same name and correct it by removing one of the entries(if the time of realising the duplicate name and time of entering the duplicate name is not separated too far away).

---