search

ruijietay / pe

0 stars 0 forks source link

Adding a unique phone and email with a name that exists in the application is not allowed #3

Open ruijietay opened 2 months ago

ruijietay commented 2 months ago

Steps to reproduce

  1. Launch TutorPro
  2. Enter command add n/John Doe p/98765432 e/johndoe@gmail.com a/Clementi Ave 123, Blk 321, #12-345 lvl/P5 sub/math-B sub/science-C
  3. Modify phone and email to 98765433 and johndoe@gmail.con, and enter a second command, add n/John Doe p/98765433 e/johndoe@gmail.con a/Clementi Ave 123, Blk 321, #12-345 lvl/P5 sub/math-B sub/science-C
  4. Error shown This student already exists in the address book

Expected As mentioned in the UG:

Hence, we should be able to add a new student to the address book with a different number and email but same name.

Actual When we change the phone number and email to be unique (with the name being the same as someone in the current address book), the error shown is This student already exists in the address book.

image.png

This might pose a problem to common names such as Ryan, especially since I can't add two students with the same name but with different numbers and emails.

soc-se-bot commented 2 months ago

Team's Response

No details provided by team.

The 'Original' Bug

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

TutorPro allows duplicate persons with same name and email

Outline The UG states that TutorPro does not allow duplicate persons. They can have the same name but phone and email must be unique.

Evidence in UG Screenshot 2024-04-19 at 4.47.27 PM.png

What actually happens? It seems that TutorPro actually does not allow people of same names, but allows people of same phone and email. Please see the evidence below.

Why Medium Severity If users don't figure this out themselves, they might not be able to enter any users as TutorPro will block the command actions. The UG and app behaviour are different.

Same name different phone and email: Screenshot See index 9 and my command input.

Screenshot 2024-04-19 at 4.50.52 PM.png

Different name but same phone and email: Screenshot See index 11 and 12.

Screenshot 2024-04-19 at 4.49.57 PM.png

[original: nus-cs2103-AY2324S2/pe-interim#5216] [original labels: type.FunctionalityBug severity.Medium]

Their Response to the 'Original' Bug

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

This is actually a documentation bug as it is intended for students to be able to have the same phone number and email. This is because especially for younger students, their point-of-contact might be their parents, and if they have the same point-of-contact, they will have the same phone number and email.

Hence this part is a low severity documentation bug.

For the name part, it is a functionality bug. However, this will not cause a huge inconvenience to the user as they can just add numbering if they happen to have students/parents with the same names, e.g. if there are 3 Jane Does (which is already highly unlikely), they can just save their contact names as Jane Doe 1, Jane Doe 2, and Jane Doe 3.

Hence, this bug with the names is not as important as the work already done in v1.4. Hence, it is a low severity documentation bug.

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)

Reason for disagreement: The duplicate bug report contains two different bugs:

  1. Different names with same phone and email (UG claims to be not allowed, but program allows it) For this bug, the team responded that it is a documentation bug (that it should be the expected behaviour from their explanation above)

  2. Same name but different phone and email (UG claims to be allowed, but program disallows it) For this bug, the team responded that it is indeed a functionality bug, but decided to mark the entire issue as a low severity documentation bug (probably to just address the first bug above).

Hence, I believe that my issue should not be marked as a duplicate of the aforementioned issue, since the team has chosen to only address the first bug.

## :question: Issue type Team chose [`type.DocumentationBug`] Originally [`type.FunctionalityBug`] - [x] I disagree **Reason for disagreement:** As seen in the reasoning for the disagreement for `Issue duplicate status`, the team decided to put this as a documentation bug to address the first bug in that issue. However, from the team's response to the second bug in the duplicate issue, they have admitted that it is indeed a functionality bug (which is the same bug as my bug report for this issue).
## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]