There is no validation of unique contact details

[FriedCabbageSalad]

No validation can cause contacts to have the same contact details which would detract from the apps purpose to manage multiple clients in the event of wrong inputs

[nus-se-bot]

Team's Response

We allow this in our app because our app is meant for financial consultants who may have corporate clients working at the same company (and thus, same company phone numbers)

The 'Original' Bug

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

Able to add duplicate persons with all same attributes but different names

Step 1: add n/John Doe c/ABC Inc. p/98765432 e/johnd@example.com a/John street, block 123, #01 01 Step 2: add n/Jon Doe c/ABC Inc. p/98765432 e/johnd@example.com a/John street, block 123, #01 01 Step 3: add n/Jo Doe c/ABC Inc. p/98765432 e/johnd@example.com a/John street, block 123, #01 01

Severity: Low

Justification: I am able to add in several people(3) with different name but all other attributes are the same. In the real world, it is nearly impossible to have multiple people with the same phone number and attributes and as such i don't think it should be allowed. While the user may accidentally make mistakes and add several people with same attributes, it adds a slight inconvenience to user, but the user would be able to continue using the application

---

_{[original: nus-cs2103-AY2425S1/pe-interim#2570] [original labels: type.FeatureFlaw severity.Low]}

Their Response to the 'Original' Bug

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

We allow this in our app because our app is meant for financial consultants who may have corporate clients working at the same company (and thus, same company phone numbers, company address, corporate email, and obviously same company name). This follows the principle of allowing flexibility for users.

They must have different names, which means that they are not duplicates. In fact, if you tried to repeat this with all same attributes (including name), the app would flag it as an error and inform you of duplicate persons.

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.Rejected`] - [x] I disagree **Reason for disagreement:** In your response, you mention the target group being "corporate clients working at the same company" as such they might have the same company phone number or email to be the reason of rejection. However, there is no mention of them being in the same company at all in the user guide (see image). As such, I disagree with the response as the target group is stated in the user guide to be any "clients and their transactions", as such, the clients could be from separate entities (companies). Allowing them to have the same contact details (phone number and email) would result in difficulties and issues in contacting specific clients in the event of mistakes. Eg **name:** John Doe **phone number**: 12345678 **email:** JohnDoe@abc.com **company:** ABC company **name:** Joseph Lee **phone number**: 12345678 **email:** JosephLee@xyz.com **company:** XYZ company It is reasonable to assume that a consultant may make in mistake in copy-pasting the phone number of a client over. Should he then call the Joseph Lee to discuss his transaction details but since the number belongs to John Doe, the consultant would be illegally discussing private information belonging to Joseph. The same line of thought applies to having the same email. Additionally, the argument of clients in the same company having the same company phone numbers and corporate email does not make sense. Contacting a client for a business transaction would not occur using the common business helpline or email but rather company work phones, which would have unique numbers for the individual. Additionally, corporate emails are also often different from one another, having unique identifiers in them such as name or id number. As such, it would be more realistic to disallow having the same phone number and email in light of corporate reality. 

---