Open jannaleong opened 4 months ago
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.
Team chose [response.NotInScope
]
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.
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.