Open woojiahao opened 10 months ago
Thank you for pointing it out, but this is an intended behaviour. The user should not input the same name as mentioned in the screenshot below, no matter under lead or client, which means if D.A.V.E. contains a John Doe
client, another John Doe
lead or client should not exist.
Team chose [response.Rejected
]
Reason for disagreement: The team's response does not address the root of the report and that is that the error message is clearly incorrect and can mislead users. I have acknowledged the restriction of having case-sensitive same name, however, by having the error message as "This lead already exists in the address book", when clearly the duplication occurs due to an existing client, the error message only serves to mislead and confuse users into thinking that there is a lead with the name John Doe, which is completely wrong. The steps I have detailed for reproducing the bug is clear and just because duplicate names are not allowed, does not mean that the error message can incorrectly classify the issue.
If a client already exists with the same name as an intended lead, the error message should be something like "A client with the name 'John Doe' already exists in the address book", allowing users to properly diagnose their problem and rectify it.
Steps to reproduce
Command
addlead n/John Doe p/98765432 e/johnd@email.com a/322, Clement Ave 2, #02-25 t/classmate k/18/12/2003
Images
Justification
This is a medium functionality bug as users who are creating leads will not expect a lead and client to be case sensitive in terms of the name and this can result in them being unable to add a lead and client who may have the same name and hinder their usage of the application as they may be looking for a lead named "John Doe" without realising that it's the client that violates this duplicity rule instead