Open danielleloh opened 4 months ago
Thank you for pointing out this issue. After careful consideration, we have decided that addressing the uniqueness of individuals based solely on their name is a complex challenge that extends beyond the scope of our current module, hence we have labelled this bug as NotInScope. Our team has decided to keep the implementation simple and adhere to the AB3 approach for checking uniqueness by name.
Furthermore, there is a good workaround for users to mitigate this issue, that is for users to add a nickname/indication to differentiate between two contacts of individuals with the same name. This would be similar to how one would normally save the contacts of two people with the same name in real life. Adding the nickname/indication also allows the user to identify and differentiate the two individuals. If users were to allowed to add people with the same names instead, they may end up facing difficulties distinguishing between the two contacts when attempting to look up one of the individuals, potentially leading to confusion or errors in communication.
Team chose [response.NotInScope
]
Reason for disagreement: Thank you for the response.
addressing the uniqueness of individuals based solely on their name is a complex challenge that extends beyond the scope of our current module
I disagree with this point made. Although I understand that learning about primary keys and unique keys in data is not being taught in our module, I think that it is common knowledge that an individual's name is not unique. This can be very commonly observed around us — e.g. in my personal contact list consisting less than 1000 contacts alone, I already have 3 people saved under the name bernice
, 2 people saved under the name megan
etc.
there is a good workaround for users to mitigate this issue, that is for users to add a nickname/indication to differentiate between two contacts of individuals with the same name.
Firstly, from the user guide and the developer guide, I interpret that the application was made for student leaders to manage large amounts of contact information (1000 and below) for people involved in different school-wide events.
There is no mention on whether this application was made for formal or informal (personal) purposes.
Shown below are the screenshots of where I obtained these information:
Firstly, when managing large amounts of people, the likelihood of people having the same name increases.
Moreover, for a student leader managing large amounts of people from multiple events, it is unrealistic to expect him/her to be close enough to have a nickname / remember nicknames for everyone involved in the events.
Lastly, it is not stated explicitly if the application is to be used for personal reasons or official reasons. If the app were to be used for official reasons (e.g. storing emergency contacts for official emergency protocols), it would not be appropriate to store nicknames as it will then not be consistent with data stored in the school's system.
Therefore, I deem this a feature flaw because disallowing the addition of people with same names causes the application to not be reasonably useful.
If users were to allowed to add people with the same names instead, they may end up facing difficulties distinguishing between the two contacts when attempting to look up one of the individuals, potentially leading to confusion or errors in communication.
I disagree with this. Yes, there is a chance for potential mix-ups between people with the same name. However, the information stored under a person e.g. their email address, phone number, tags should be the clear distinguishing factor between who's who, instead of their names.
Hope this clarifies your doubts!
steps to reproduce
add person with the following:
add n/cookie monster a/sesame street p/91234567 e/cookie.monster@example.com
then add another person with the following input:
add n/cookie monster a/test address p/81234567 e/test@example.com
expected
allows the addition of second person with the same name but different information (e.g. email, address, or phone number).
This is because there is a likelihood of two persons having the same name in an event.
actual
displays an error message : This person already exists in the address book
screenshots
other comments
you may want to consider changing the identifying parameter to something more unique like email address of a person.