nus-se-bot
commented
2 years ago Team's Response
Reason for lower severity: Only affects users who do not follow the format.
Such allowance will not affect the user adding the contact as if the user is following the format properly, even in erroneous input situation, there will be one less parameter prefix that is typed in which will throw an error to the user to prompt invalid command format. Hence this only happens during deliberate sabotage.
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: I disagree and this is a possible mistake that a user might make during an input. (i.e. typing 2 n/ prefixes is a possible error that a user might make) I agree that the user guide has explicitly mentioned this but there is no error message or any preventive measures to ensure this does not happen to a user. In the case that the user actually makes such an error, the application should prompt the user and prevent this.
:question: Issue severity
Team chose [severity.Low]
Originally [severity.Medium]
- [x] I disagree
Reason for disagreement: This is not a rare occurrence as typos can happen. Also, this can impact the user if he/she is unaware about this issue and assumes that his/her input is correct. e.g. user intends to add "Bob Tan" but uses the n/ prefix twice by accident "n/Bob Tan n/Bob", this would lead to "Bob" being added as the name but the user might assume that "Bob Tan" is added instead, due to negligence
Input command given:
Expected: Throw an error and explicitly mention that only 1 name input is allowed.
Actual: Allows the contact to be added and the name takes the 2nd name input.
Suggestion: This is not explicitly mentioned in the UG and this can lead to users unintentionally adding the wrong contact. In the UG, it clearly shows that:
The user can easily interpret that only one input should be allowed for name, phone, email and address each. This error also applies to the other 3 fields (phone, email, address)