search

lamchenghou / pe

0 stars 0 forks source link

Duplicate names are not handled #2

Open lamchenghou opened 10 months ago

lamchenghou commented 10 months ago

People with the same name, phone number and email can be added (different casing)

To reproduce: add n/alEx yeOH p/4595644589 e/testuser@gmail.com o/OCCUPATION a/ADDRESS [t/TAG]...[appt/APPOINTMENT_DATE] \ add n/alEX yeOH p/4595644589 e/testuser@gmail.com o/OCCUPATION a/ADDRESS [t/TAG]...[appt/APPOINTMENT_DATE]

Result: Duplicate persons added

soc-pe-bot commented 10 months ago

Team's Response

Duplicate detection for name (Capitalisation). Resolving #4758 resolves this as well.

The 'Original' Bug

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

Unintuitive case sensitivity for name

Names are case-sensitive in the app (e.g. kimberly tan is different from Kimberly Tan). However, this does not accurately represent names in real life, which are not case-sensitive. As a result, duplicate persons might not be detected if the user mistakenly adds the same person but with their names in a different case.

Moreover, the case sensitivity of names is not stated clearly in the User Guide, increasingly the likelihood of the above happening.

Screenshot 2023-11-17 at 4.55.56 PM.png

[original: nus-cs2103-AY2324S1/pe-interim#3879] [original labels: severity.Low type.FeatureFlaw]

Their Response to the 'Original' Bug

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

Yes. Should have more precise parsing for names/duplicate detection for names, specifically capitalisation.

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)

Reason for disagreement: [replace this with your explanation]

## :question: Issue type Team chose [`type.FeatureFlaw`] Originally [`type.FunctionalityBug`] - [x] I disagree **Reason for disagreement:** This should be a functionality bug as legitimate user behaviour (duplicate names) is not handled. It differs from normal expectations, because it seems they're using name as a primary key/unique identifier. This may cause serious issues as described in `Low -> Medium` comment. It could be seen in terms of a flaw too, as in their design has problems.
## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** This is highly likely to be `severity.Medium`. - It is common to accidentally input 2 names, due to forgetfulness / typo. (adding 2 clients twice accidentally, because I forgot I had added you. It's likely both times will have differing casing, but the same name) - With this, updating is done using `INDEX`. Hence, copy 1 of person might not be updated & accidental copy 2 of person will be updated. This leads to data inconsistency, which might cause issues such as the FA calling the wrong number / visiting an old house of the client. This will definitely cause occasional inconvenience, especially if the FA's client base grows to a huge size. The produce is still useable, thus `Medium`.