nus-pe-bot
commented
9 months ago Team's Response
We have identified this to be a duplicate as it relates to the duplication detection logic in general.
The 'Original' Bug
[The team marked this bug as a duplicate of the following bug]
Duplicate detection did not catch extra white space for staff name
Steps: Added Staff with name "John Doe" -> Added another Staff with name "John Doe" (same name but with an extra space in between)
Both names should be detected by the application as the same person and catch for user's accidental error of typing an extra space, however Tran$act allowed for "John Doe" to be added too.
Perhaps, Tran$act can catch this duplicate names and throw an error to the user.
[original: nus-cs2103-AY2324S1/pe-interim#1746] [original labels: severity.Low type.FeatureFlaw]
Their Response to the 'Original' Bug
[This is the team's response to the above 'original' bug]
No details provided by team.
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)
- [x] I disagree
Reason for disagreement: 
I refer to the screenshot above from the CS2103T website. Here is why these 2 issues are not duplicates
- The extra white space problem and the case sensitivity problem are independent and distinct - we have to fix different aspects of the parser to fix both problems (e.g. toLowerCase to validate differences in cases, regex logic to replace consecutive spaces with a single space)
While both problems are related to the parser, the solution to the two problems are different. Hence, they are not duplicate issues.
## :question: Issue response Team chose [`response.NotInScope`] - [x] I disagree **Reason for disagreement:**  I refer to the screenshot on CS2103T website - here is why I do not think they have done enough to warrant this bug a response.NotInScope 1. Fixing this feature flaw is essential for the app to be reasonably useful. Accidentally inputting different cases/forgetting what case I inputted before for my previous entries are extremely common for an application driven by CLI commands. 2. Case-insensitive duplicate validation can be implemented without much additional effort. Since the AB3 parser already extracts the entire block of content under the parameter name, the team simply needs to call toLowerCase() on the string before performing the equals() check. This is fairly simple to implement. 3. Even if we cannot accept the above 2 arguments, the team has not made clear the limitations of the duplicate detection feature in their user guide/GUI. Hence, as a user, I am "led to believe that duplicates are being detected while many potential duplicate cases go undetected" as per the screenshot from CS2103T website. Hence, I believe that the response cannot be classified as NotInScope. This bug is a FeatureFlaw.
## :question: Issue type Team chose [`type.FeatureFlaw`] Originally [`type.FunctionalityBug`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]
## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:**  I refer to the screenshot above from CS2103T website. This FeatureFlaw is not severity.Low because it does not appear only in very rare situations. Typing different cases is extremely common for an application driven by CLI commands. It is likely to affect the normal operations of the product because remaining duplicates will still exist in the directory if only one copy is deleted, editing one contact will still cause the remaining contacts to be outdated, etc. Hence, I believe that this FeatureFlaw is severity.Medium.
Intuitively, 'john Doe' and 'John Doe' are the same person. It is probably a typo on the user's end. However, the duplication detection logic is not sensitive to differences in cases. Given this bug, it is very common for users to key in duplicate entries so I assigned severity.Medium.