[ https://issues.apache.org/jira/browse/FINERACT-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Santosh Math updated FINERACT-405: ---------------------------------- Labels: gsoc p2 (was: p2) > Client/Staff SMS phone number back-end validation, incl. default country code > ----------------------------------------------------------------------------- > > Key: FINERACT-405 > URL: https://issues.apache.org/jira/browse/FINERACT-405 > Project: Apache Fineract > Issue Type: New Feature > Reporter: Santosh Math > Assignee: Markus Geiss > Priority: Trivial > Labels: gsoc, p2 > > Reported by [~vorburger] at https://mifosforge.jira.com/browse/MIFOSX-779 > Original Description: > We'll likely start with just using String / VARCHAR as type for SMS phone > numbers in client/staff, but in order get serious about SMS support, the > "data quality" of those will quickly be fairly import. > Therefore, it would probably be very useful if the platform technically > enforced that such phone numbers are always represented and stored in the > database including country code prefix (using the +91 ... notation). > The should also have some validation logic in the UI enforcing this > (FrontlineSMS says: "This number is not in international format. This may > cause problems matching messages to contacts."). > The UI could assist in making it easier to capture phone numbers and propose > a default country code saved in some System Administration configuration > somewhere when entering new phone numbers. > The Java back-end could use some proper strongly typed self validating > PhoneNumber value object type, instead of just passing around String? May be > something like this exists already? -- This message was sent by Atlassian JIRA (v7.6.3#76005)