Phone number format does not allow for country codes

[gavingoh99]

Occasionally, there might be a need to keep in touch with foreign clients or contacts, especially in the context of social work.

However, SWEE does not currently support country codes since phone numbers can only contain numbers. Without such a functionality, it could be incredibly difficult for the user to know the country code extension associated with a particular number, limiting the scope of the app to local numbers and contacts only which could inevitably fall short in use case for some social workers.

Steps to reproduce:

1. add --name=Theodore Koo --phone=+6598001715 --email=theodore@example.com --addr=Prince Street, Block 144, #19-14 --tags=Disabled --note=Lactose Intolerant

Resultant output:

To alleviate this, there could be workarounds that the team could provide in order to not restrict the application's use case!

[soc-se-bot]

Team's Response

There is an obvious work-around to this, which is to remove the "+" sign and just input the phone number as "6598001715".

Alternatively, the country code can be added in the note field.

We disallowed symbols like "+" to ensure that the input is a valid phone number.

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

• [x] I disagree

Reason for disagreement: Thanks for providing workarounds.

However, I feel that the workarounds provided may still be inadequate.

With regard to storing the phone number with the country code as in "6598001715", I refer to the Wikipedia page on telephone numbers (https://en.wikipedia.org/wiki/List_of_mobile_telephone_prefixes_by_country):

In the Republic of Chad, phone numbers can have the mobile prefix "65" followed by 8 numbers used to distinguish phone numbers internally. Under this format, "6598001715" could potentially be a number belonging to someone in Chad. A user could confuse this number which was originally a Singaporean number with a number of someone from Chad without their country code (+235). Thus, in this regard, the ambiguity of the situation makes the first workaround inadequate.

Furthermore, I note that the notes field appears to be a "catch-all" for a lot of the team's workarounds in response to bug reports. While there should be no issues surrounding this, a quick survey of the restrictions of the notes field says otherwise. In the example provided by the UG, a notes field could contain a remark like "Daughter is the primary caretaker."

If we were to follow the suggestion of this workaround and include the country code, it could look like this "Daughter is the primary caretaker. Country code is +235".

Next, I note that a possible workaround suggested by the team for storing names that otherwise would be invalid is to also store them in the notes. Formats like "s/o" which are common in Singapore would have to be stored in the notes field too, so now we have a notes field that contains "Daughter is the primary caretaker. Country code is +235. Full Name: Bob s/o Charles".

The notes field which was introduced to store additional information now appears to be a convenient workaround for all potential bugs. But what happens when an aspect changes? Editing the notes field requires that a user copies the entire field and ammends it accordingly since the edit command replaces the field with the provided argument. This is inherently inconvenient and adds a severe barrier that takes away from the convenience afforded to users of the application.

---

## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]

---