search

nus-cs2103-AY2425S1 / pe-dev-response

0 stars 0 forks source link

Duplicate persons can be added where the only difference is the lower case in the name #745

Open nus-pe-bot opened 1 week ago

nus-pe-bot commented 1 week ago

Expected: NAME is ideally case-insensitive to prevent duplicate persons from being added to the contacts

Actual: Both John Doe and John doe can be added to the contacts with the same other information

Steps to Reproduce:

  1. add n/John Doe p/98765432 e/johnd@example.com t/classmates
  2. add n/John doe p/98765432 e/johnd@example.com t/classmates

While this intended behaviour is justified in the UG as "increased flexibility", it may cause errors for users who expect input validation to prevent duplicate entries especially when you explicitly do not intend for duplicate guests to be added.

image.png

[original: nus-cs2103-AY2425S1/pe-interim#1053] [original labels: severity.Medium type.FeatureFlaw]

kvernnn commented 1 week ago

Team's Response

We recognise the concern. However, the purpose of having a case-sensitive name input is to allow greater flexibility for users to distinguish guests with similar names. For example, the name 'Jiaxin' may be spelt differently (officially) such as JiaXin and Jiaxin. Users may also wish to distinguish the guest based on their preferences, especially if the user has an internal system on how he wishes to enter the names (all lowercase, all uppercase etc.).

Restricting the name input to be case insensitive would require the user to input a longer name to identify each of them, increasing hassle for the users. For example, to distinguish JiaXin and Jiaxin, their surnames would then be needed. Yet this might not even be sufficient enough to differentiate them if both full names are Tan Jiaxin and Tan JiaXin officially.

Moreover, since it was explicitly stated in the UG, users should not expect input validation for case sensitivity. Hence, we feel that this is not an issue as it is expected behaviour that our team has explicitly intended. Though, we recognise that further developments are possible to distinguish different guests that is not in our current scope of work.

Duplicate status (if any):

--