Open C5hives opened 1 week ago
Thank you for the feedback, our current implementation of Bizbook uses the name as the identifier and thus we wanted to allow as much flexibility in setting the name, thus the decision for case sensitive names.
However, we do agree that this is a feature flaw, and thus in a future iteration (stated in our planned enhancement), we intend to fix this, by switching the unique identifier to another more concrete variable, such as phone number. This change would then allow contacts of same name, as it is quite common for people of the same name irl.
Team chose [type.FeatureFlaw
]
Originally [type.FunctionalityBug
]
Reason for disagreement: [replace this with your explanation]
Inputs: First command:
add n/John Doe p/98765432 e/johnd@example.com a/John street, block 123, #01-01
Thenadd n/JOHN DOE p/98765432 e/johnd@example.com a/John street, block 123, #01-01
(note the capitalised name)Expected Output:
This person already exists in the address book
Actual Output:
New person added...
As real-world names are usually not case sensitive, this may cause the user to accidentally create a new person when a duplicate already exists (e.g. they accidentally hit the caps lock button midway through typing the name)
UG might also be misleading as it has the following disclaimer: