nus-pe-script
commented
5 days ago Team's Response
Thank you for your bug report! We have listed this bug to be a duplicate of #470 as changing a method in the Client class will fix both issue.
The 'Original' Bug
[The team marked this bug as a duplicate of the following bug]
Duplicate contact handling
If I add somebody named John, then proceed to add another person named John but with a different phone number and email and address from the previous john - it still raises an error just because the names are the same.
However, the specification in the UG was that " Clients are considered duplicates if NAME and PHONE match with another existing client"
But in this case only the name matches yet it is considered a duplicate contact so either the functionality is wrong or the UG must be updated.
[original: nus-cs2103-AY2425S1/pe-interim#665] [original labels: severity.Low type.FunctionalityBug]
Their Response to the 'Original' Bug
[This is the team's response to the above 'original' bug]
Thank you for your bug report! There certainly was an issue with the checks and we agree with the severity and type given by the tester.
Items for the Tester to Verify
:question: Issue duplicate status
Team chose to mark this issue as a duplicate of another issue (as explained in the Team's response above)
- [ ] I disagree
Reason for disagreement: [replace this with your explanation]
## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.High`] - [x] I disagree **Reason for disagreement:** Upon further understanding this bug, I would like to propose `severity.Medium` for this bug **Core Functionality Impact:** This bug directly impacts the functionality of a contact management system, specifically the ability to add and manage clients with the same name—a very common scenario. While the system remains usable, users are forced to adopt workarounds that compromise data integrity and usability. **Business Impact Analysis:** In real-world scenarios, it's not uncommon for businesses to encounter clients with the same name. This bug systematically affects such cases by: - Preventing users from adding valid, distinct clients who share a name but have different contact details. - Forcing users to create artificial name variations (e.g., adding a suffix or middle initial) to bypass the error, leading to: - Data integrity issues. - Retrieval and communication challenges, as the client records won't align with real-world identifiers. **UG Specification Violation:** The User Guide explicitly states that duplicate detection is based on **both name and phone number matching**. This bug flags duplicates based on name alone, contradicting the UG and creating confusion for users. **Severity Justification:** Based on the rubric: - **Severity.Medium:** This bug fits because it causes **systematic inconvenience** to users managing clients with common names, a regular occurrence in most business environments. - While users can technically continue using the product with workarounds, these workarounds: - Lead to additional effort and confusion. - Affect data quality and integrity. - Introduce problems in client communications and retrieval. This goes beyond a minor inconvenience but does not render the product completely unusable, making Medium severity the most appropriate classification.
The UG specifies that the duplicates are checked based on Name and Phone
This is ambiguous as I was not sure if both had to be the same, or any one had to be the same
When I had put different name and same number, it did not give any error (see person 3 in the below image)
But when I put the same name, different phone, it gave an error:
Clients can often have the same name with different phone numbers, while having the same phone number is very rare unless they are using their family's contact.
Thus this form of validation will lead to errors
This will also result in users unable to add clients with same name, which is a major issue