Add functionality, ability to add two separate students with the same phone number.

[ChanWeiJie]

To recreate this : enter the following

1. add n/Bob p/87654321 e/bob@u.nus.edu a/123, Clementi Ave 16, [UI] Application Version not updated. #1-321
2. add n/Bob2 p/87654321 e/bob@u.nus.edu a/123, Clementi Ave 16, [UI] Application Version not updated. #1-321

From the result the app allows the duplication of phone for 2 separate person (only names were checked for duplication), as shown below :

This is a bug as two or more students should not have the same phone number.

Expected : Error to be thrown when there is a duplicate in phone number.

[soc-se-bot]

Team's Response

They are essentially the same bug report for different fields.

The 'Original' Bug

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

Add functionality, ability to add different persons with the same email.

To recreate this : enter the following

1. add n/Bob p/87654321 e/bob@u.nus.edu a/123, Clementi Ave 16, [UI] Application Version not updated. #1-321
2. add n/Bob2 p/87654321 e/bob@u.nus.edu a/123, Clementi Ave 16, [UI] Application Version not updated. #1-321

From the result the app allows the duplication of email for 2 separate person (only names were checked for duplication), as shown below :

This is a bug as two or more students should not have the same email address.

Expected : Error to be thrown when there is a duplicate in email address.

---

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

Their Response to the 'Original' Bug

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

UG explains that only duplicate names will be rejected, not email. Moreover, this is an intended feature as sharing of emails among distinct persons do exist (especially for organizational email domains that do not always have a unique email for each distinct person). This also falls in line of preventing "Overzealous input validation", where we allow flexibility in this input field for the users.

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: I disagree that this bug can be marked as a duplicate. This is because as shown below a bug can only be considered as a duplicate when the exact same bug reported multiple times not the same "TYPE" of bug. OR When a bug cannot be fixed independently (Meaning fixing A would also fix B if B is a duplicate of A). As such in the senario, fixing the parsing of Email would not fix the parsing to Name as they are 2 separate classes as shown below. Hence this bug should not be marked as a duplicate.

---

❓ Issue response

Team chose [response.Rejected]

• I disagree

Reason for disagreement: I disagree that this bug should be rejected as this application is targeted to students and other users based from their user stories in the DG. As such, the organization mentioned above by the team would most probably be a school organization. Hence in the real world, schools would definately not allow users/students to have the exact simillar phone numbers (for the purpose of distinguishing recipient when calling them). Asides from the organization, this would also cause inconvenience to the students/users themselves as they would get conufsed when 2 of their friends have the same phone number.
Furthermore on the point of "Overzealous input validation", i agree that allowing flexibility in this input field for the users is good. However as shown below, it is mentioned that "a lack of proper handling either via blocking or warning for potentially invalid inputs can still be considered a bug." Which in this case it is as the product doesnt block or warn me about the invalid inputs.

---

❓ Issue type

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

• I disagree

Reason for disagreement: [replace this with your explanation]

---