6. Invalid phone numbers

[rahhulleee]

Super long phone number as shown above is allowed and in real life context such a phone number shouldn't exist. (North Korea has the longest phone number capped at 17 digits)

[nus-pe-script]

Team's Response

Our team has discussed this issue and we find that adding these limitations will be seen as implementing overzealous input validation. Our current implementation allows for flexibility which can in turn allow the user to use the software in their own way of preference, while taking your suggestion may lead to overzealous rejection of inputs can annoy the user.

• We reject this as our function exhibits expected and correct behavior.

https://nus-cs2103-ay2324s2.github.io/website/admin/tp-pe.html#feature-flaws-2

• This is also not a functionality bug as our features intentionally accept long PHONE inputs as expected.

  Items for the Tester to Verify

  :question: Issue response

Team chose [response.Rejected]

• [x] I disagree

Reason for disagreement: The whole application might be affected as a very long and overzealous input will make the box containing Client information very big and long, and readability might be affected.

The example of an overzealous input provided is fine as it is harmless to the UI. However look at this example.

The entire UI is affected and readability of the application is affected. I believe that there should be a reasonable limit placed on the number of characters allowed - and this would help in validity checking as well. Lets say there's a corruption of your income level or phone number and this long number is what the phone number becomes. There is obviously a corruption and the limit should allow for the validity of the data to be ensured as well. In retrospect, what if allowing this long number and hence the UI bugs and unreadability annoy the user instead. Once again I am reiterating how realistic the overzealous inputs have to be. The example provided above is indeed pretty realistic but a VERY and UNREALISTICALLY long phone number shouldn't be allowed. :DD

---

## :question: Issue type Team chose [`type.FeatureFlaw`] Originally [`type.FunctionalityBug`] - [x] I disagree **Reason for disagreement:**  In accordance with this, it is not a feature flaw but rather a functionality bug. Your add feature is fine and this doesn't affect the add feature in any way but rather, the functionality of the whole application might be affected as a very long and overzealous input will make the box containing Client information very big and long, and readability might be affected.

---