al_international_phone: Use `isValidPhone` over `isValidPhonePrecise`?

[BryceStevenWilley]

Once #315 merges, we have the option of two different validation methods: isValidPhone, and isValidPhonePrecise.

• isValidPhone (previously called isPossiblePhone) just checks based on the phone number's length, and is more 'future proof'
• isValidPhonePrecise (previously called isValidPhone) is the behavior this feature has used: checks that area codes and first few digits of the number are valid.

More details about the two

Even though we've been using Precise, it will and does get out of date: area codes have continued to be added, including one in 2023 (730). The intl-tel-input library has mentioned that it should be updated frequently (with area codes being added possibly monthly).

So the two questions:

• is it worth it to let users authors choose whether to use isValidPhone or isValidPhonePrecise?
• do we switch Suffolk interviews to use isValidPhone?

[plocket]

1. I think if we use isValidPhone we probably don't need to offer the users a choice. I'm not sure about isValidPhonePrecise.
2. Keeping isValidPhonePrecise will mean we need to update regularly. It looks like their preferred cadence is once or twice a month, though there have been bigger gaps. Do we want to try to keep up with that cadence? We could set up automatic updates, though I'm a little reluctant to automatically merge external library changes. We could set up a reminder action to make a PR once a month/quarter, but that will necessitate human intervention.

[BryceStevenWilley]

1. I think I mispoke originally: when I said users, I meant interview authors.

2. Yeah, that's my main question here. Monthly is quite a bit of work, and also expecting other devs to keep it updated that often is a lot to ask.

[plocket]

Offering the option to authors seems pretty trivial. I know some who would say that it still adds a maintenance burden and I can't gainsay it.

Regarding the automation, I was the one misspeak there! I didn't mean to include "reminder". I meant to say the action could just make a PR. It could include a link to somewhere relevant to checking the source of the update. It would still be maintenance cost.

Beyond that I'll let @nonprofittechy and you to hash out the capacity of the project.

[nonprofittechy]

I think according to our own guidance, we should be less strict with phone number validation: https://assemblyline.suffolklitlab.org/docs/style_guide/question_style_validation#when-to-avoid-input-validation

I guess changing the behavior from the existing might cause a problem for someone though.

[BryceStevenWilley]

I guess changing the behavior from the existing might cause a problem for someone though.

Yeah, my guess is that usually if someone opted into using this data type, they were probably looking for a more strict validation, as opposed to just a normal text phone input (with the exception of us changing the phone input in AssemblyLine).

My suggestion based on this:

• add another param that turns on / off precise validation, default to on
• in our interviews, use that custom param to be off

[plocket]

Those sound reasonable. I think this change can stand alone, though, as it preserves existing behavior.

[nonprofittechy]

That sounds like the right choice to me too

[nonprofittechy]

We talked this through live; we agree with this solution:

1. Switch AssemblyLine to use looser validation
2. Probably switch default to the loose validation so devs need to opt in to the stricter validation
3. Look into soft validation. Might be easier in this case because it's already a JavaScript widget.