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

PhoneNumberPrefixWidget improvement for regions sharing same country prefix #493

Merged
merged 1 commit into from
Jun 14, 2022

Conversation

amateja
Copy link
Collaborator

@amateja amateja commented Mar 2, 2022

As promised in #251 this PR improves PhoneNumberPrefixWidget handling for regions sharing the same country prefix. Current behavior does not follow requirements for Select.Choices. Choices should be indexed by unique values and this requirement was not met for 12 country prefixes.

Fixes #133
Fixes #251
Fixes #489

@francoisfreitag francoisfreitag self-requested a review March 3, 2022 14:11
@francoisfreitag
Copy link
Collaborator

Early commits look good, could you move them into separate PRs so we can keep this PR focused on the change for regions sharing the same country prefix?

@amateja
Copy link
Collaborator Author

amateja commented Mar 9, 2022

Hi @francoisfreitag

I've extracted whatever was not directly and strictly linked to this fix (which wasn't that much) and I'm going to use it in separate PR. I've also reorganized commits to show as clearly as I could my journey through this case.

Regards
Andrzej

Copy link
Collaborator

@francoisfreitag francoisfreitag left a comment

Choose a reason for hiding this comment

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

Great work! That’s solving some of the most active issues in the repository, coming with a nice set of tests.
Thanks a lot for the contribution. 🎉

phonenumber_field/widgets.py Show resolved Hide resolved
phonenumber_field/widgets.py Outdated Show resolved Hide resolved
phonenumber_field/widgets.py Outdated Show resolved Hide resolved
phonenumber_field/widgets.py Outdated Show resolved Hide resolved
}
value = widget.value_from_datadict(data, {}, "field")
self.assertEqual(value.as_e164, "+1123")
self.assertTrue(hasattr(value, "_region"))
Copy link
Collaborator

Choose a reason for hiding this comment

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

Suggested change
self.assertTrue(hasattr(value, "_region"))
self.assertEqual(value._region, "US")

phonenumber_field/widgets.py Outdated Show resolved Hide resolved
phonenumber_field/widgets.py Outdated Show resolved Hide resolved
phonenumber_field/widgets.py Outdated Show resolved Hide resolved
tests/test_widgets.py Outdated Show resolved Hide resolved
tests/test_widgets.py Outdated Show resolved Hide resolved
Copy link
Collaborator

@francoisfreitag francoisfreitag left a comment

Choose a reason for hiding this comment

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

Thanks for the rework, this is definitely close to landing. It’s a valuable contribution and the project will definitely be improved by it, thanks a lot for taking the time to upstream it!
The discussion on the patch is only meant to ensure its maintainability, trying hard to avoid mistakes. Your work is definitely appreciated and most welcome 👍.

Remaining open points:

  • How can an str value be passed to decompress()?
  • Please write the new tests at a more functional level, that better explain the use case than a unit test calling into Django multi widget methods. It’s also much easier to call Django multi widget method in a non-representative than when manipulating the form.

Edit: Removed the str guard from decompress and corresponding test.

phonenumber_field/widgets.py Outdated Show resolved Hide resolved
Comment on lines 74 to 75
if isinstance(value, str):
value = to_python(value, region=region)
Copy link
Collaborator

Choose a reason for hiding this comment

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

I’m failing to see why this is needed?
The only test failing when this code is removed is test_decompress_valid_str, which does not represent how an str can get to decompress. Can you write a functional test that calls decompress with a non-empty str? I would probably replace test_decompress_valid_str with that functional test.

tests/test_widgets.py Outdated Show resolved Hide resolved
tests/test_widgets.py Outdated Show resolved Hide resolved
tests/test_widgets.py Outdated Show resolved Hide resolved
@J4bbi
Copy link

J4bbi commented May 26, 2022

Many thanks @amateja for this quality PR. It seems to fix exactly the issue I am having (Guernsey and UK sharing prefixes).

If possible, could you please respond to @francoisfreitag 's issues so that this might be merged?

If @amateja is too busy. Can we consider either pushing to this PR (not sure if that's possible) or re-submitting one with code you are 100% okay with @francoisfreitag ?

My aim here is not to show anyone disrespect in any way, just to improve the library. Otherwise I will have to apply @amateja 's fix directly to my local copy.

@francoisfreitag
Copy link
Collaborator

Ideally, @amateja can take this work to the finish line. His contribution is great, and I’m eager to integrate it. The question blocking me from merging currently is “How can an str value be passed to decompress()” (and related #493 (comment))?
A test is the best way to demonstrate the use case, but even steps to reproduce or details about how that can happen are sufficient. I am happy to write the corresponding test and apply the edits suggested in past reviews.

Of course, if others interested in this PR understand the reason for that guard, please share it.

@francoisfreitag
Copy link
Collaborator

Without response, I have gone ahead and applied the last cleanups to this patch.
Integrating and releasing it soon.

Many thanks to @amateja, it’s a great contribution to this project! 🌟

Each choice should be indexed with a unique value, use the region ISO code
over the national prefix.

Fixes stefanfoulis#133
Fixes stefanfoulis#251
Fixes stefanfoulis#489
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
3 participants