nus-pe-bot
commented
3 years ago Team's Response
Thank you the bug report, however, we have decided to reject this bug.
We believe that this bug is invalid as this is the expected behaviour, which has been explained in our UG very clearly, as seen below (row 2 of the table shown in screenshot 1 and the example 2, which is exactly the same situation being reported) :
We expect that the user would have read this part of the UG, and come to the conclusion of not giving invalid prefixes (like the situation that you have raised).
Additionally, when the user inputs an invalid prefix, it will throw an error, and allow the user to correct his input. This is a reasonable behaviour (and the same as AB3). The feature works, thus, it is not justifed to put such a bug as high severity, which means this bug makes the application totally unusable. We have decided to downgrade the severity to very low, as we believe this was a misunderstanding on the tester's part, since we have already explicitly explained the usage scenario for invalid prefixes.
Furthermore, this is also a bug inherited from AB3, on top of the fact that this is exactly the same as the expected behaviour for tCheck's parser according to our UG.
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [ ] I disagree
Reason for disagreement: [replace this with your explanation]
:question: Issue severity
Team chose [severity.VeryLow]
Originally [severity.High]
- [ ] I disagree
Reason for disagreement: [replace this with your explanation]
Steps to reproduce:
c-add n/John Doe p/98765432 e/81234567 a/Blk 123 ABC Road t/Friday X/asinto the command box and press enter.Expected: Command to parse successfully by ignoring
X/asor show an error prompt detailing a wrong prefixXis used.Actual: Error prompts me to ensure all tag names are alphanumeric which they already are.