search

medic / cht-core

The CHT Core Framework makes it faster to build responsive, offline-first digital health apps that equip health workers to provide better care in their communities. It is a central resource of the Community Health Toolkit.
https://communityhealthtoolkit.org
GNU Affero General Public License v3.0
467 stars 217 forks source link

Check if a phone number is mobile or fixed line #8718

Open 1yuv opened 11 months ago

1yuv commented 11 months ago

What feature do you want to improve? Allow an option to validate if given phone is Fixed line or Mobile number. Most of the time, when phone is registered on CHT, they're used for reporting or sending SMS. CHT currently allows user to input valid phone numbers

Describe the improvement you'd like If we're allowing to input fixed line numbers, to which messages can not be delivered, gateway phone tries and will fail. This impacts CHT performance, caused gateway to send messages to phones where message can not be sent or delivered at all.

Describe alternatives you've considered Allow a validation to be passed when tel input is used. Or, introduce a new type mobile which accepts only mobile phone numbers.

Additional context medic/config-moh-nepal#1067

garethbowen commented 11 months ago

The lib we use for formatting and validation has a function to getNumberType which returns one of these types: https://javadoc.io/doc/com.googlecode.libphonenumber/libphonenumber/latest/com/google/i18n/phonenumbers/PhoneNumberUtil.PhoneNumberType.html

Should be reasonably easy to implement. I think I'd prefer validation options rather than a new type.

Possibly related: https://github.com/medic/cht-core/issues/6390

1yuv commented 11 months ago

I also quickly verified by parsing some numbers on the library's node copy. This looks possible for most of the countries where it's possible to distinguish mobile number and fixed line numbers.

1yuv commented 11 months ago

I think I'd prefer validation options rather than a new type.

If we want to do using validation, is it using constraint on forms? Isn't that mostly the part of enketo? Can we write our constraint functions? I was more inclined towards adding a new type mobile, supporting only mobile phones and keeping tel to support both fixed line and mobile.

garethbowen commented 11 months ago

We provide our own phone widget which validates against libphonenumber: https://github.com/medic/cht-core/blob/master/webapp/src/js/enketo/widgets/phone-widget.js

I don't know how to indicate different validation modes, but maybe we can use appearance?

1yuv commented 9 months ago

I'm removing my assignment given other priorities and leave it open for people to contribute to.

garethbowen commented 9 months ago

There's a solution being investigated for https://github.com/medic/cht-core/issues/8681 which includes the ability to pass parameters to widgets which I think would be helpful here too.

jkuester commented 2 weeks ago

For the record, it should now be trivial to pass params to the Phone Widget following the pattern set for the instance::cht:unique_tel in https://github.com/medic/cht-core/pull/9340.

For example, you could add a column to your form: like instance::cht:require_sms_support. Then, in the phone-widget code, we would just need some simple logic to read the data-cht-require_sms_support attribute and customize the libphonenumber call as necessary.

binokaryg commented 2 weeks ago

Could we extend the current phone_validation setting?

Phone numbers can be entered using SMS forms also.

jkuester commented 2 weeks ago

Sure, the phone-widget is already passing the settings values. The main impact of using an app_settings configuration is that it would apply to all phone numbers in all forms (unless you wanted to get really fancy...). But, maybe that would be desired behavior?

garethbowen commented 2 weeks ago

The other problem is you may want "full + mobile" or "partial + mobile", ie: they are two separate concepts, so we should define them separately.

I prefer passing params to the form because as @jkuester says this means you can have different validation for different fields.

binokaryg commented 2 weeks ago

I prefer passing params to the form

In that case, we will also need a way to specify the phone number type in an SMS/JSON form configuration.

garethbowen commented 1 week ago

we will also need a way to specify the phone number type in an SMS/JSON form configuration.

Would a new pupil validation rule, or the ability to pass a param to the existing validPhone rule work?

binokaryg commented 1 week ago

Would a new pupil validation rule, or the ability to pass a param to the existing validPhone rule work?

I think it should work as long as it is configurable.