Mailing-List: contact dev-help@fineract.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@fineract.incubator.apache.org
Date: Thu, 23 Feb 2017 10:27:44 +0000 (UTC)
From: "Santosh Math (JIRA)" <jira@apache.org>
To: dev@fineract.incubator.apache.org
Message-ID: <JIRA.13045573.1487845627000.41618.1487845664232@Atlassian.JIRA>
In-Reply-To: <JIRA.13045573.1487845627000@Atlassian.JIRA>
References: <JIRA.13045573.1487845627000@Atlassian.JIRA> <JIRA.13045573.1487845627369@jira-lw-us.apache.org>
Subject: [jira] [Created] (FINERACT-405) Client/Staff SMS phone number
 back-end validation, incl. default country code
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Thu, 23 Feb 2017 10:27:55 -0000

Santosh Math created FINERACT-405:
-------------------------------------

             Summary: 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


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
(v6.3.15#6346)