Open bhnuka opened 10 months ago
Due to the lack of screenshots and explanations provided on your end, this is our current understanding of your issue.
The definition of invalid is not as narrowly defined as just the specifications highlighted in the fields table as suggested by the test. Attempting to add a person that already exists (i.e. duplicate person) will be a case of adding invalid particulars, as seen in the potential errors table: "This person already exists in the address book”. It should then be clear to the tester that the user should take the correct step to resolve the error message by removing/amending the invalid particulars.
As such, the reported bug of missing the extension of a duplicate person is unnecessary, as our current extension of invalid input already covers the case of adding a duplicate person. Repeating this in another extension does not bring any extra value.
Team chose [response.Rejected
]
Reason for disagreement: Despite your assertation that "Invalid" is not narrowly defined, the language used definitely leads the user to believe as such (Given how the only error message with the word "Invalid" is for invalid command format). Developers may be confused when their command format is correct but they still face the same error.
Additionally, in UC07, where you add tags to a person in the contact list, you clearly break down each potential error into separate extensions, showing that you already employ this format for other UCs. As such, I still believe this issue to be a valid one as it omits valuable information regarding extensions.
Additionally, as per the CS2103/T website, missing extensions is a valid issue for Documentation Bugs. I feel as though this is especially so in a case where the function already has many potential errors.
Lacks the duplicate person extension for when adding a new person who already exists. Just stating that the particulars are invalid is insufficient (As all the particulars abide by the remarks for valid fields)