search

kvernnn / pe

0 stars 0 forks source link

Add Command Allows Duplicate Numbers #5

Open kvernnn opened 3 days ago

kvernnn commented 3 days ago

image.png

Steps:

  1. Running the command add n/John Doe p/98765432 e/johnd@example.com a/311, Clementi Ave 2, #02-25 dr/Software Engineer s/Java, Python, C++ ex/Project Manager at Google from 2010-2020 st/Interviewed note/Super confident t/friends t/owesMoney adds John Doe into the address book
  2. Run command add n/JOHN DOE p/98765432 e/johnd@example.com a/311, Clementi Ave 2, #02-25 dr/Software Engineer s/Java, Python, C++ ex/Project Manager at Google from 2010-2020 st/Interviewed note/Super confident t/friends t/owesMoney
  3. Expected: Command fails since UG specifies that add command does not allow the same candidate to be added twice based on phone number and name
  4. Actual: JOHN DOE is successfully added though they have the same number

This contradicts with the specifications in the UG. Users might assume that the application checks the duplicate inputs for them but in actuality it does not, which might cause inconveniences in the future when they realise two contacts have the same number.

soc-pe-bot commented 9 hours ago

Team's Response

Thank you for raising this issue. After reviewing the reported behavior, we would like to clarify the following:

Explanation of Behavior: Our implementation of duplicate detection considers both name and phone number to determine if two candidates are the same. However, duplicate detection is case-sensitive for the name field. This behavior aligns with our intended design and allows flexibility for users to distinguish between candidates who might have similar details but differ in the capitalization of their names (e.g., "John Doe" and "JOHN DOE" may refer to different entities in some contexts).

The current design ensures that:

Two entries with the same name and phone number are disallowed. Entries with the same phone number but different name cases (e.g., "John Doe" vs. "JOHN DOE") are treated as distinct. This is explicitly stated in our User Guide, where duplicate detection considers the name and phone number combination. There is no mention of enforcing case insensitivity for the name field, and the current behavior is consistent with the stated rules.

Addressing the Issue: As per the PE Grading Guidelines, this behavior does not qualify as a Functionality Bug because: The behavior does not differ from the specifications in the User Guide. The UG does not explicitly state that name matching is case-insensitive. The current behavior supports a legitimate user scenario where two individuals may share the same phone number but have names that differ in capitalization. Recommendation: We recognize that case-insensitive duplicate detection for names may provide additional user convenience, but it is not essential for the current version of the product. This could be a potential enhancement for future iterations, but for now, we respectfully classify this issue as response.NotInScope.

Items for the Tester to Verify

:question: Issue response

Team chose [response.NotInScope]

Reason for disagreement: [replace this with your explanation]

## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]