Phone number exceeding 15 digits are allowed

[nus-se-script]

When a 16 digit phone number is used to create a doctor using the following command, doctor creation was successful. However, the longest phone number in the world (inclusive of country code) is only 15 digits. Users might have entered 1/2 extra digits by mistake but the command does not guard against this behaviour as it should.

createD n/test p/1234567890123456 e/x@gmail.com a/test

---

_{[original: nus-cs2103-AY2425S1/pe-interim#1642] [original labels: type.FeatureFlaw severity.Low]}

[Nigeltzy]

Team's Response

Hi! Thank you for the bug report. We understand your concerns with regards to phone number input validation. Our team did not set up any further constraints than the one we currently have in place (must have at least 3 numbers) as we believe that doing so would fall under overzealous input validation.

While it is true that the E.164 Limitation would lend to a phone number with a maximum of 15 digits, our target audience / users (medical staff) often meet people from many different walks of life, which lends to them having many different numbers. There are many instances where our user may want to record a number longer than 15 digits for a patient or doctor. For example, Dual-Tone Multi-Frequency Tones (DTMF) are not restricted to the E.164 limit because they are part of in-call communication. Similarly, many customer service systems are designed to accept long inputs and the maximum length of such numbers are not restricted by phone standards. In the event that the patient / doctor to be recorded can only / would only like to be contacted via such methods, the user / medical staff would have to record their contact details accordingly.

In the event that a patient or doctor wishes to record their phone number where relevant under such schemes, we do not wish for our application to prevent this. When faced with such long numbers, the user is free to record it under the phone number tab while including any relevant details in the remarks column to facilitate future contacting of the patient / doctor.

Our team sees your point and agrees that there can be value in validation of phone numbers, however, given the constraints and context of the project, we do not believe this to be a vital and crucial feature to implement first, over other functionality that may be more important. Validation of phone numbers is a much more complex process that involves factoring in countries, personal context and background, or alternatively may involve generations of OTPs / acknowledgement messages -- which we believe is not a priority.

Hence, coupled with the fact that the input did not crash the app, corrupt the data, or make the app unusable, we believe that this should be considered NotInScope.

Duplicate status (if any):

--