[FeatureFlaw] Overzealous Input Validation - Name

[juliusgambe]

Feature Flaw:

Unable to add people of the same name with different phone number and email. Severity is medium as one may have friends of the same name and a user may not be able to know their full name to differentiate (Their full name could also be the same). This may only annoy users as they may have to change the name a bit and since you do not accept special characters, the ability to differentiate might be even more limited.

Example: Ryan Tan, Muhammad Syafiq etc. are common names

Email and phone number validation could be sufficient already.

Actual Output

Steps To Reproduce

1. Open app
2. Add a John Doe with phone number, email
3. Add another the same John Doe with different phone number and different email.

[nus-pe-script]

Team's Response

No details provided by team.

The 'Original' Bug

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

People with the same name should be allowed

Currently, people with the same name are not allowed to be added again into the contact list. However, in reality, there are many people with the same name and this constraint can cause a lot of inconvenience. I think that disallowing people with the same phone number or email is a sufficient condition for duplicate person.

---

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

Their Response to the 'Original' Bug

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

We recognise this could potentially cause some minor conveniences when using our features, but rectifying it is not important because the inconvenience of needing to save all your contacts that have the same name with more context (eg "Alex from CS" and "Alex from Biz") to adhere to the constraints is negligible compared to the inconvenience caused by confusion over multiple contacts having the same name. This is because in the real world and in the context of our app, no student would identify their contacts using their phone number or email, and rectifying it is less important (based on the value considerations) than the work that has been done already.

As such, it was actually part of our considerations to disallow contacts with the same name.

However, we are categorising this as a featureflaw that is out of scope because from a certain point of view, it could be a suboptimal design. Since most students would already differentiate their contacts by name, and 1. The UG specifies this constraint. 2. When the user attempts to add a second person with the same name, the software gives a suitable error message, this meets the requirements for an out-of-scope response.

Thank you so much for the feedback!

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`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]

---