Team's Response

Thank you for your bug report. We understand your concern about data consistency and would like to clarify more on the rationale behind non-unique fields.

In our application, we have decided that names are unique to identify people with respect to the needs of our target audience. However, allowing Telegram Handles, phone numbers and email addresses to be duplicated is an intentional choice of our application. This applies for both the addPerson and editPerson commands.  Making addresses not unique was more straightforward as multiple people can live in the same place. However, for the other fields, there was more to consider. In some cases, it is possible that a contact does not want to disclose their direct personal details (phone number / email / Telegram). They may instead disclose a more general phone contact. Some examples where multiple people may share the same contact details include:

Any contacts who might share landline numbers instead of their personal numbers. Multiple people can share the same landline. For instance, suitemates might use a landline number.
Residential Fellows, Staff, Hall Leaders might share the Hall / Dorm’s contact information for privacy / formal means settling dorm-related expenses. For instance, it would be important for them to go through the dorm’s management office to get proper reimbursement. This leads to multiple people sharing a single office’s contact (email / phone number / Telegram).
Staff might use a common, share email for communication.
People from clubs, societies, and organisations might use a common Telegram Handle, phone number, email as a single point of contact.
Contacts might have broken phones / no SIM, and may need to share their contacts with another person (phone number / Telegram) temporarily.

 We aim to be flexible with our application, only restricting uniqueness in names as it is necessary, whereas giving the freedom for users to have duplicates in other fields. Overly enforcing the uniqueness of fields can be seen as overzealous validation that may inconvenience our target audience who may encounter contacts with common details. This design decision aligns with real examples that accommodates to the diverse user needs, and follows common standards in leading contact management applications such as Apple Contacts where flexibility in contact details is allowed.

Items for the Tester to Verify

:question: Issue response

Team chose [response.NotInScope]

[x] I disagree

Reason for disagreement: Thank you for the detailed explanation regarding the intentional decision to allow non-unique identifiers in Spend N Split. I appreciate the consideration given to various scenarios; however, I'd like to express my disagreement with the justification provided.

The core purpose of Spend N Split is to facilitate payment settlements among university students, emphasizing accurate and unique contact information until payment settlement. Your rationale suggesting that individuals might not want to disclose personal details contradicts the fundamental objective of this application. It's crucial to emphasize that for payment settlement purposes, accurate and unique personal details are imperative to ensure seamless transactions and data integrity.

The examples provided, such as shared landline numbers or common contacts for clubs and organizations, don't align with the application's primary objective. In payment settlements, the expectation is to deal directly with individuals, not communal or generic contact details. In current settings, everyone uses a phone, and reliance on shared landlines or generic contacts is increasingly uncommon, especially among university students.

Moreover, the suggestion that individuals might use shared contacts due to broken phones seems more like a hypothetical scenario rather than a practical consideration for a payment-oriented application. The argument lacks relevance in the context of Spend N Split's primary function, which necessitates accurate and individualized contact information. This point seems like something made up just to refute my original point, rather than a conscious thought during design decisions.

While Apple Contacts might offer flexibility, Spend N Split serves a distinct purpose, focusing on payment settlements where precision and accuracy in contact details hold paramount importance. Allowing duplicates or generic information could potentially compromise the app's functionality and defeat its intended purpose, leading to data inconsistencies and confusion during payment settlements.

I urge reconsideration of this design choice in light of Spend N Split's core functionality. Ensuring uniqueness in identifiers like phone numbers, emails, and Telegram handles aligns more closely with the app's primary goal of facilitating accurate and seamless payment settlements among individuals.

Hence, I disagree with the Dev Team's response and feel this is clearly a Medium severity Functionality Bug which has potential to impair the application's core functionality.

eyelessrhyme7 / pe

Edit Command Allows Assigning Unique Identifiers (Telegram, Email, Phone) to multiple entries #3

Team's Response

Items for the Tester to Verify

:question: Issue response