soc-pe-bot
commented
4 months ago Team's Response
Thank you for the suggestion. This application is for recording details of individual patients, therefore a handphone number is expected for the field. Nevertheless, this is a useful suggestion to be considered in future iterations, when the application is scaled to record details of organizations.
Items for the Tester to Verify
:question: Issue response
Team chose [response.NotInScope]
- [x] I disagree
Reason for disagreement: As shown in the the tp guideline below, overzealous blocking of phone numbers is a feature flaw.
Yes to address your comment, I understand that a phone number is expected in this field. However, I do not think you understand the nature of my bug.
The issue I am pointing out is with regards to your field not being able to accept any other inputs that are not numbers. As a result, common numbers such +65 93467483 or 1234 5678 (HP) (<- provided example in the tp guideline) would not be allowed in your application. This is problematic as it greatly limits the phone numbers that doctors can save.
Furthermore as show in the guideline below, something is a feature flaw when the blocking of an input might not add any value but allowing it does. Following the guideline, this is a feature flaw as blocking special characters does not add value and instead, limits the user as it disallows them from entering conventional numbers. However, allowing special characters allows the user more flexibility to put in conventional phone numbers. Allowing for such cases will also not hinder the operation of your software in any way.
## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** Numbers such as +65 97347840 with a special character (+) is a conventional Singaporean phone number. This is not a very rare situation that will inconvenience users in only very rare scenarios. This is especially so for doctors who may see foreign patients. it is typical for foreigners to seek medical attention at GPs. in this case, recording their area code (for eg. +91 for india), would be necessary which this app does not allow for. Furthermore, as the current implementation only allows for numbers, phone numbers such as 1234 5678 (HP), provided in tp guideline, will also not be accepted. This is the same for any numbers with special characters. Because these are standard numbers and that many cases of phone numbers will be disallowed, it will at least cause some occasional inconvenience to some users. Thus it is medium severity.
input : create ic/T0123456G hp/+1-800-555-1234 a/311, Clementi Ave 2, #02-25 dob/1990-01-01 s/F st/PENDING e/janed@example.com bt/A+ n/Jane Doe output : error message telling me that my phone number input is not valid
Expected that the command will allow this telephone number as it is a common contact for organisations. However the command blocks special characters. This is a problematic as it greatly limits user to only phone numbers with no extra symbols.