Duplicate Telegram handles allowed

[sushiyade]

Steps to reproduce: addPerson n=Betsy Crowe t=friend e=betsycrowe@example.com a=London Block 55 p=1234567 tg=@London addPerson n=Betssy Crowe t=friend e=betsycrowe@example.com a=London Block 55 p=1234567 tg=@London

This allows for 2 people to have share a telegram handle, when they are supposed to be unique. Is there a reason for allowing this?

[nus-pe-script]

Team's Response

Thank you for your bug report. This is a duplicate of another issue, but the same response applies.

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.

The 'Original' Bug

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

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

Description: Edit command only checks for name duplicates, and allows assigning other unique identifiers (telegram, email, phone) the same value for multiple contacts.

Details:

Steps to Reproduce:

1. Open the application using default jar data.
2. edit 1st and 2nd person to have the exact same data apart from Name and Balance
3. No errors or warnings displayed.

Expected Behavior: Should display an error/warning when trying to edit unique information about a person and assigning it as the same as that of another person.

Actual Behavior: No error/warning displayed.

Severity/Type Label: This issue can be categorized as a medium severity bug, as it can lead to data inconsistencies and unexpected results, it critically affect the application's core functionality as a contact management application made for payment settlements. It's possible that this behavior is not intentional and addressing it can improve the application's data management integrity and user experience.

Suggestion for Improvement: To address this issue, it's essential to ensure that the edit command checks certain attributes which should be unique for a contactBook such as phone, email, telegram. This will help maintain data integrity and provide a more reliable and intuitive user experience when performing edits.

Below, entry#1 and entry#2 both have the same details apart from name and balance.

---

_{[original: nus-cs2103-AY2324S1/pe-interim#5793] [original labels: type.FunctionalityBug severity.Medium]}

Their Response to the 'Original' Bug

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

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 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]

---

## :question: Issue response Team chose [`response.NotInScope`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]

---

## :question: Issue severity Team chose [`severity.Medium`] Originally [`severity.Low`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]

---