jaejayrome / pe

0 stars 0 forks source link

Parents can have same phone number #4

Open jaejayrome opened 4 months ago

jaejayrome commented 4 months ago

Description: It was mentioned previously that amongst students it doesn't make sense for them to have the same phone numbers, but this constraint should be applied to parents as well.

Steps to Reproduce:

  1. Enter 2 parents with the same phone number

Evidence: Screenshot 2024-04-19 at 4.35.48 PM.png

Suggestions: Bring the constraints of the students over to parents as well since it wouldn't make sense for parents to have the same phone number just as with the reasoning for students.

nus-se-script commented 4 months ago

Team's Response

As explained in #489, which is also a duplicate of #5368

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: [replace this with your explanation]


## :question: Issue type Team chose [`type.DocumentationBug`] Originally [`type.FunctionalityBug`] - [x] I disagree **Reason for disagreement:** I disagree because when I first read the UG, the rationale mentioned in the UG stating that how 2 persons in the application should have unique phone number or email addresses is valid, a similar bug ticket that was raised by me as well highlighted that this behaviour can be observed between a parent and a student. The previous argument that 'younger students' might not have the capacity to have a phone number or an email address would not be able to translate to this situation since this bug report is mentioning how the same phone number is being used by 2 adults at the same time, while you might argue that this can happen, most applications today have incorporated a common business logic that a phone number would be unique to a particular user. An example would be how phone numbers being unique to a user can lead to a future extension of OTP verification. Also, nothing relevant was mentioned in the non-functional requirements to support your claim, which led me to conclude that this is a functionality bug.