limjeremy496 / pe

0 stars 0 forks source link

Duplicate phone number allowed can pose a problem for users #2

Open limjeremy496 opened 2 weeks ago

limjeremy496 commented 2 weeks ago

Although duplicate names are handled in user guide, it is also essential to handle duplicate phone numbers, as they can pose an issue when another person has the same phone number.

image.png Although it is a user error, it is better to ensure users are not able to do so. Especially when users tend to copy data from excel, and my look at the same number for a different user.

nus-pe-script commented 2 weeks ago

Team's Response

Thank you for bringing this up, however our team believes that duplicate phone numbers should be allowed for the purpose of the app (planning weddings). Many wedding attendees belong to the same family and involve children who may not have their own unique phone number. Some families, especially older generations, will also use their home phone or their family member's mobile phone as their mode of contact. Hence, some guests will inevitably share the same phone number. Enforcing this restriction would bring about more inconvenience for users. It is the intended behaviour that our team decided to implement and not a bug.

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

Reason for disagreement: I acknowledge the team's rationale for allowing duplicate phone numbers, particularly in the context of wedding planning where shared family numbers are common. However, the lack of explicit mention in the User Guide about this design decision creates ambiguity for users. Duplicate phone numbers could introduce risks, such as misidentification during RSVP tracking or when updating guest details, which could compromise the app's reliability.

Rather than enforcing strict uniqueness, which may inconvenience users, a compromise would be to issue a warning when a duplicate number is detected. This approach preserves flexibility while increasing user awareness, reducing the likelihood of unintended errors. Additionally, documenting this intended behavior in the User Guide would ensure clarity for users.

It might be considered not in scope rather than a bug since functionality does seem to align with app's purpose. However, without documentation, the current behavior can be seen as inconsistent with user expectations.