search

shawnnlimm / pe

0 stars 0 forks source link

UG does not specify uniqueness of person of add command #5

Open shawnnlimm opened 5 months ago

shawnnlimm commented 5 months ago

Description

After playing around with the add command, I am still unsure how a person is uniquely identified, which is not specified in the UG. If I were to guess, I think it is the combination of (n/NAME, p/PHONE_NUMBER).

Steps to reproduce

  1. Execute add n/hanni pham p/87654321 a/999A t/friend d/tdy 10am-12pm
  2. Execute add n/john doe p/87654321 a/999A t/friend d/tdy 10am-12pm

Expected Behaviour

john doe should not be added, since it is very unlikely that 2 different people have the same phone number

Actual Behaviour

john doe is is added successfully

image.png

Label elaboration

Severity: Medium, since it causes inconvenience as users have to figure out themselves what constitutes as a duplicate person, although this problem is only occasional.

BugType: FeatureFlaw, since it is unlikely that 2 people have the same phone number.

nus-pe-bot commented 5 months ago

Team's Response

This is not a feature flaw, this is intended behavior; multiple contacts can have the same contact number (e.g., a parent and a child).

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

Reason for disagreement: I disagree that this bug should be rejected as there is clearly an inconvenience caused to the user when using the app. As a new user following the UG, there is no information regarding how uniqueness of a person is defined for the app.

Furthermore, the app currently allows 2 people with the same name but different phone numbers to be added too which is valid, since different people might have the same name. However, if multiple contacts have the same contact number, then it is also very possible (although rare) that multiple contacts have the same name AND contact number, which the app should allow instead of rejecting.

If 2 different people indeed have the same contact number (parent and child), perhaps a better way would be to have some unique identifier for each person, such as NRIC number in Singapore, which is definitely unique to each person.

## :question: Issue type Team chose [`type.DocumentationBug`] Originally [`type.FeatureFlaw`] - [x] I disagree **Reason for disagreement:** I disagree that it is of `type.DocumentationBug` since this problem is related to duplicate detection and the way the app handles duplicates can definitely be improved. Furthermore, the limitations of the duplicate detection feature were not made clear to the user.
## :question: Issue severity Team chose [`severity.VeryLow`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** I disagree that it is of `severity.VeryLow` since it is clearly not purely a cosmetic problem. Instead, it is a problem related to duplicate detection which will cause occasional inconvenience to users if they do not know what the app considers as duplicates. Also, there is a possibility that the app detects a new person (same name and contact) as a duplicate although they are not.