Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove old phonenumber validation #5294

Open
wants to merge 9 commits into
base: main
Choose a base branch
from

Conversation

rparke
Copy link
Contributor

@rparke rparke commented Nov 12, 2024

No description provided.

@rparke rparke force-pushed the remove-old-phonenumber-validation branch from 07014d8 to f096108 Compare November 12, 2024 13:54
Copy link
Contributor

@CrystalPea CrystalPea left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey, nice work!

I think we just need to look into there 3-digit numbers for service contact details - as we probably still want to support these?

@pytest.mark.parametrize(
"short_number, allowed",
(
("119", True),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the question should be - are there valid cases where service's contact number is a three-digit number?

It looks like it might be from this list? https://www.inyourarea.co.uk/news/10-three-digit-phone-numbers-and-what-theyre-for

For example Track and Trace had a 3-digit number, and there are some other ones.

I wonder how we previously validated this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is an easy fix, and it's an exception to pure libphonenumber validation I'm okay with adding. We can either have an allow list, or just say "any 3 digit number that successfully parses to a "possible" UK number, we are just going to say is valid"

@rparke rparke force-pushed the remove-old-phonenumber-validation branch 2 times, most recently from bf3a83f to 6fa938c Compare November 20, 2024 18:57
requirements.in Outdated
@@ -17,7 +17,7 @@ notifications-python-client==10.0.0
fido2==1.1.3

# Run `make bump-utils` to update to the latest version
notifications-utils @ git+https://github.com/alphagov/notifications-utils.git@f676a72f212ba9d8b1e8cc4dc5fd3211a2214960
notifications-utils @ git+https://github.com/alphagov/notifications-utils.git@de4d6573a0dfb5969156b5a7595f00c54f492cc0
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

needs updating to semver'd tag once that has been merged

Copy link
Contributor

@CrystalPea CrystalPea left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great, nicely done with contact phone numbers validation 🙌🏼

Ready to merge when utils are merged and requirements updated 👍🏼

@rparke rparke force-pushed the remove-old-phonenumber-validation branch 3 times, most recently from 6f49f33 to 2e3ef21 Compare November 25, 2024 13:12
@rparke rparke marked this pull request as ready for review November 25, 2024 13:12
Phonenumbers automatically rejects both emergency and non-emergency (3 digit numbers). Need to consider whether we should test this here or re-write the code to reflect this change
returning a human readable phone number is a common use case for lots of the front end validation code. This introduces a utility function for this use
a consequence of using validation code based on libphonenumber is that a lot of numbers we previously thought were valid phone numbers that we could test against were in fact invalid. Keeping those numbers in our tests breaks because our libphonenumber based validation will throw unexpected exceptions for numbers that simply aren't possible or valid
…n_emergency 3 digit numbers and numbers with extentions

The python port of libphonenumber is much stricter than our old bespoke validation code. As a result it does not accept phone numbers with extensions or phone numbers with 3 digits. This change incorporates the changes to utils that throw an appropriate error, and adds a crude method for handling numbers with extensions. The form will accept any number that returns a TOO_LONG error code, assuming it must be because of an extension (this shouldn't matter as we are not validating whether the phone number is real for notify to send sms notifications to. The service owner will be confident that they're providing the correct number for their service)
@rparke rparke force-pushed the remove-old-phonenumber-validation branch from 2e3ef21 to b951ef6 Compare November 28, 2024 16:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants