LG-8976: Allow using Puerto Rico phone numbers for hybrid handoff#7874
LG-8976: Allow using Puerto Rico phone numbers for hybrid handoff#7874
Conversation
727f848 to
956ea79
Compare
There was a problem hiding this comment.
We were updating the underlying country code <select> on change, but not on initialization.
3b294ce to
747601c
Compare
Looks like we can have disagreement between what the backend thinks the country is and what the frontend does. Here we're letting the frontend win.
…e blocking some Puerto Rico users from using their phones to take pictures of their identity documents.
Was leading to input being initialized to "+1"
Use Phonelib to parse the country out of the user's phone number and intialize the `international_code` dropdown rendered by `PhoneInputComponent` Update `PhoneFormatter` to use `national` format for the default country (US), `international` for others.
This change probably broke a bunch of tests anyway
Init from previous_params if there, otherwise infer from phone number. (There are some cases where the international_code value is not submitted, e.g. fetch() calls) Also took the opportunity to integrate new tests better with existing test infra
747601c to
53c314e
Compare
We format PR numbers as just (XXX) XXX-XXXX on the front end
app/forms/idv/phone_form.rb
Outdated
| user_phone = MfaContext.new(user).phone_configurations.take&.phone | ||
| user_phone if valid_phone?(user_phone, phone_confirmed: true) | ||
| # @return [Array<string,string>] The international_code and phone values to use. | ||
| def determine_initial_values(international_code: nil, phone: nil, **_) |
There was a problem hiding this comment.
Previously, we were initializing the phone field but not the international_code field. This could lead to cases where non-US phone numbers would end up not passing client-side validation, since the PhoneInputComponent would attempt to parse them as with a US country code.
| const country = iti.getSelectedCountryData(); | ||
| if (country.iso2 && this.codeInput) { | ||
| this.codeInput.value = country.iso2.toUpperCase(); | ||
| } |
There was a problem hiding this comment.
Is it important that we avoid the change event that would be triggered by calling to syncCountryChangeToCodeInput instead?
| const country = iti.getSelectedCountryData(); | |
| if (country.iso2 && this.codeInput) { | |
| this.codeInput.value = country.iso2.toUpperCase(); | |
| } | |
| this.syncCountryChangeToCodeInput(); |
There was a problem hiding this comment.
Also, could we add some JavaScript test coverage for these changes?
There was a problem hiding this comment.
Yeah, I originally tried just calling syncCountryChangeToCodeInput, but I believe it would replace a blank value with "+1" initially, which looked strange.
(These are slow tests)
Don't include a spread arg
🎫 Ticket
LG-8976
(Also a dash of LG-8839, since I was in there.)
🛠 Summary of changes
A user reported an issue using their Puerto Rican phone number for IdV's hybrid handoff screen. In this case, they had their phone number prefilled, since they were using it for SMS 2FA. It's likely this came in with #7762.
📜 Testing Plan