Open choaticman opened 1 week ago
We note that this issue could cause an inconvenience to some users as they are unable to add duplicate names with different fields, and thus are unable to add different clients with the same name. Our application has opted for a stricter definition of duplicate clients, and therefore users are unable to add clients of the same name (case insensitive).
However, we do not think that this issue would make the application unusable to most users as they are able to use workarounds such as adding descriptors to the names (i.e. Differentiating between Alex Yeoh
and Alex Yeoh NUS
). Thus, users are still able to use the application albeit with an inconvenience. Hence the severity should be reduced to Medium.
Furthermore, we have mentioned this in the User Guide to avoid any confusion for the users.
Team chose [severity.Medium
]
Originally [severity.High
]
Reason for disagreement: [replace this with your explanation]
Two buyer who has the same name, but different phone number and email are considered the same person, when they are clearly not. Rationale for severity: This is of high severity due to how common it is in the real world to share the same name with someone else.
Commands Executed:
buyer n/Test1 p/87654321 e/test@t.tt
buyer n/Test1 p/12345678 e/test1@t.tt
Expected Result: The application allows adding the second buyer named Test1
Actual Result: