soc-pe-bot
commented
1 year ago Team's Response
No details provided by team.
The 'Original' Bug
[The team marked this bug as a duplicate of the following bug]
Able to add a task with semantically same name as a existing task in the tasklist
To reproduce: addTask n/create uiux design d/use po pr/HIGH c/DATABASE dl/2022-11-12;
Expected: Error message restricting addition of task with same name as an existing task with same name
Actual: Task is added.
[original: nus-cs2103-AY2223S1/pe-interim#4719] [original labels: type.FunctionalityBug severity.Low]
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 believe the team might have misinterpreted the issue. What the bug this issue is raising is that it is possible to edit a task's name to be semantically the same as its existing name. It is not about editing a task's name to be semantically the same as that of another existing task in the task list. By "semantically the same", it means names that differ by casing of a letter or extra whitespace between words.
Introducing a fix to the "original" bug could fix another bug of a task's name being edited to one that is semantically equal to that of another task in the task list. It does not however fix this bug completely. It does prevent editing when given name is semantically equal to its existing name. However, error message returned is still incorrect. As stated, expected error message should be something like "all values given must be different from existing values of task to be edited". However, the error message given after original" bug is fixed would be something along the lines of "another task with the same name already exists". This is due to how duplicate detection in adding tasks is independent of the check for all new values given to be different from that of task to be edited in editing tasks.
In addition, this bug can be fixed independently by fixing the check for all values given to be different from that of task to be edited to account for inputs that are semantically the same as existing values. This would return the expected error message when a task's name is edited to be semantically the same as its existing name and prevent editing of the task. Furthermore, employing this does not fix the "original" bug.
Hence, the two bugs are independently fixable and so I disagree with this issue being duplicate-flagged.
To reproduce: Edit a task with a name that contains an extra space between words. e.g. task to be edited has name john doe and new name is john doe.
Expected: Error message stating that all fields to be edited must be different.
Actual: Task is edited.