nus-se-script
commented
4 days ago Team's Response
There is no '0/' as part of our current prefixes. Hence, the p/ sees the input as "99999999 0/", therefore the application gives the error message which is correct message.
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: After reading your response, I understand that this is not a bug warranting being accepted. However, I believe instead of choosing to reject it a NotInScope response would be more appropriate according to the below explanation from the CS2103 site. While I understand 99999999 0/ is taken as the phone number and technically the correct error message is shown here, It would be better to have the error message explain 0/ as the root issue instead.
I do not believe I outright misunderstood the bug but was suggesting an improvement over the current behaviour of this error message. Thus, I believe a NotInScope response is better for this bug report.
Input: edit 2 t/ p/99999999 0/
The above input has a valid phone number 99999999 as specified in the UG and app as seen in the error message below. The error in this input is the addition of 0/ but the error message claims it is the phone number which is not the case as explained previously.
It would be good to change the validation/parsing to correctly pinpoint 0/ as the error and not the phone number so the user is not confused what caused the command to not work.