Possible to add student with different matriculation numbers but same phone number

[jaylontan]

Phone number should be unique as well, as not possible to have same phone numbers for 2 different people

[nus-se-script]

[IMPORTANT!: Please do not edit or reply to this comment using the GitHub UI. You can respond to it using CATcher during the next phase of the PE]

Team's Response

Duplicate students are detected only by their student ID, as stated in the UG. This we will reject this issue as we have clearly defined how a duplicate student identified.

Rationale behind allowing same phone number:
There are many instances where students may have the same number: students under the same guardian, shared contact number within a team, students without a contact may provide a shared contact (e.g. hall phone, office line) thus we have relaxed the restrictions on phone number to reflect practical usage.

The 'Original' Bug

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

Duplicate detection allows same for all fields except Student ID

Duplicate detection in add command allows for addition of two Persons with the same details (name, phone, email, project, progress and tag) except for student ID. This means that if the user accidentally adds the same Person with a typo in the student ID, Prof-iler does not check if this is intentional. This could happen to any user, at any time.

To replicate this issue, input the following commands one after another:
add n/John Doe p/98765432 id/A0253517M e/johnd@example.com pr/Prof-iler pb/72 t/Y3
add n/John Doe p/98765432 id/A0256040M e/johnd@example.com pr/Prof-iler pb/72 t/Y3

---

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

Their Response to the 'Original' Bug

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

Duplicate students are detected only by their student ID, as stated in the UG. It is unlikely for an efficient typist to make mistakes frequently, thus we will label it as severity.Low.

However, considering that this seems like a thoughtful feature, we can perhaps include a pop up message to warn the users that these 2 students may be the same. For now, this feature is not implemented in this current iteration because the only field that ought to be unique is the ID. Thus, NotInScope.

Rationale:

• common occurrence for repeated names
• shared group name, contact number, email (e.g. group leader's contact) within a group project

We have relaxed these fields to maintain flexibility.

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 response

Team chose [response.NotInScope]

• I disagree

Reason for disagreement: I disagree with it not being in scope. If the consideration for not being able to handle duplicate matric numbers is in place, the logic should be the same for phone numbers, otherwise it is contradictory.

---