Phone number validation field is too strict

[yixianggg]

As seen from the image above, the phone number validation field only allows for numbers. This could cause an issue especially for concert managers in charge of managing concerts all over the world, where most numbers would have to include country code.

Without guidelines for country codes or support for a '+' prefix, users may struggle to differentiate between local and international numbers (e.g., whether "60194723537" has a country code of "601" or "60"). Adding a standard format, such as requiring the '+' symbol for international numbers, would resolve this ambiguity. This ambiguity could cause data entry errors, especially for international contacts.

Furthermore, with many artists being represented by agents. One may wish to input multiple phone numbers, say 11111111 (Artist), 22222222 (Agent). This is not possible with the current validation field.

Overall, the strict validation could be a huge inconvenience to users.

[nus-se-bot]

Team's Response

Thanks for the report, this is indeed a valid feature flaw in our application. We will work to improve this flaw in future iterations of our project!

The 'Original' Bug

[The team marked this bug as a duplicate of the following bug]

Phone number does not accept '+' symbol

Prerequisites: None

Command to execute: addp n/John Doe p/+1 54 98765428 e/johnd@example.com a/311, Clementi Ave 2, #02-25 r/organiser t/friends t/owesMoney

Result: The command is unable to executed in the CLI and the error shown is returned. The User Guide does not specify that the users are all Singaporean or always have a Singaporean number, so there is chance for someone using a foreign number needing to add their contact but unable to specify details like country or even state code.

Suggestion: Adjust the regex used to validate phone numbers to accept '+' and other necessary characters to accommodate such users.

---

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

Their Response to the 'Original' Bug

[This is the team's response to the above 'original' bug]

Thanks for the report, this is indeed a valid feature flaw in our application. We will work to improve this flaw in future iterations of our project!

Items for the Tester to Verify

:question: Issue duplicate status

Team chose to mark this issue as a duplicate of another issue (as explained in the Team's response above)

• [ ] I disagree

Reason for disagreement: [replace this with your explanation]

---

## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** Hi! Unfortunately, I do not agree with the downgrade in severity. I feel that this is indeed a case of "overzealous input handling". Furthermore, my reason for it being of medium severity is due to the nature of the application. As a concert manager, one will have to interact with people (artists, promoters, organizers etc.) from all over the world. This means that the application should be built with this purpose in mind, since majority of the people a concert manager would have to contact may not be local. As this flaw largely affects a primary usage of the application (adding a person), I feel that the severity should not be low, as low is more for flaws that are rarely occurring (not so urgent). For this flaw, I feel that it can have large impacts on usage of the application as to reiterate, most of the contacts would have international numbers and missing out on these special characters can cause huge confusion and inconvenience.

---