Comments (8)
Makes sense, I added a warning to the PHONENUMBER_DEFAULT_FORMAT
setting in the documentation for these cases. (currently in PR #583)
from django-phonenumber-field.
This also causes extension info to be deleted after running clean()!
from django-phonenumber-field.
Hi, thanks for raising the issue. I believe the serialization (python manage.py dumpdata
) and the handling of phone number extensions works correctly, when both PHONENUMBER_DB_FORMAT
and PHONENUMBER_DEFAULT_FORMAT
are set to a format that handles extensions (RFC3966
or INTERNATIONAL
).
When either setting is set to E164
(the default), extensions are dropped, because E164 only addresses public numbers (i.e. without extensions).
The doc on PHONENUMBER_DB_FORMAT
is quite terse, and does not make it clear that you’ll need both settings.
I don’t see tests verifying phone number extension handling either, it might be a great addition. For the record, I’ve had success with the string "+33 5 55 00 00 00 ext. 66"
in my experiments.
I’ll see about addressing these issues in the upcoming weeks. Please feel free to offer pull requests, that will speed up the resolution. :)
Also, can you confirm that the library behaves as you would expect when both settings are set to an extension-compatible format?
from django-phonenumber-field.
I found the documentation mostly satisfactory here, I have both variables set to the following
PHONENUMBER_DB_FORMAT = "INTERNATIONAL"
PHONENUMBER_DEFAULT_REGION = "US"
Now in a Django shell I have a User model with a PhoneNumberField.
[ins] In [8]: user.phone_number
Out[8]: PhoneNumber(country_code=1, national_number=4158675309, extension=None, italian_leading_zero=None, number_of_leading_zeros=None, country_code_source=1, preferred_domestic_carrier_code=None)
[ins] In [9]: user.phone_number.extension = '321'
[ins] In [10]: user.phone_number
Out[10]: PhoneNumber(country_code=1, national_number=4158675309, extension='321', italian_leading_zero=None, number_of_leading_zeros=None, country_code_source=1, preferred_domestic_carrier_code=None)
[ins] In [11]: user.full_clean()
[ins] In [12]: user.phone_number
Out[12]: PhoneNumber(country_code=1, national_number=4158675309, extension=None, italian_leading_zero=None, number_of_leading_zeros=None, country_code_source=1, preferred_domestic_carrier_code=None)
Let me know if you cannot reproduce that, it's possible I'm doing something wrong still. I can tray and create a more contained reproduction as well.
Similarly, when I run python manage.py dumpdata
the phonenumber field is shown like:
"phone_number": "+14158675309",
Notice that this is not in international format, despite the settings, and that the phone number does not contain the extension. Is it possible I'm not doing the setting correctly?
from django-phonenumber-field.
You need to define PHONENUMBER_DEFAULT_FORMAT="INTERNATIONAL"
(which is different from PHONENUMBER_DEFAULT_REGION
).
>>> from phone.models import Person
>>> user = Person.objects.get()
>>> user.cell
PhoneNumber(country_code=33, national_number=555001489, extension='66', italian_leading_zero=None, number_of_leading_zeros=None, country_code_source=1, preferred_domestic_carrier_code=None)
>>> user.full_clean()
>>> user.cell
PhoneNumber(country_code=33, national_number=555001489, extension='66', italian_leading_zero=None, number_of_leading_zeros=None, country_code_source=1, preferred_domestic_carrier_code=None)
Let me know if that fixes the issue.
To confirm the settings values, you can rely on django python manage.py diffsettings | grep PHONENUMBER
.
from django-phonenumber-field.
Ah, I see! I didn't realize this was a different variable! Thanks for your patience. This did indeed fix the problem. It looks like your PR should cover this.
My testing seems to indicate that there is no issue, but I wanted to confirm; is there any risk in changing these variables with data already stored in the database? Initially I expected there to be a migration or something, but there wasn't. It seems that the field is parsed regardless of the format. It might be worth making that explicit in the docs as well.
Also feel free to close this issue, my problem is solved!
from django-phonenumber-field.
Thanks for your feedback, glad the issue is solved. 😁
is there any risk in changing these variables with data already stored in the database?
I don’t think so, as you’ve noticed, the field is parsed regardless of the format. The cases where you would be in trouble:
- Moving from an extension-compatible format to
"E164"
orNATIONAL
- changing from
PHONENUMBER_DB_FORMAT="NATIONAL"
and changingPHONENUMBER_DEFAULT_REGION
It seems that the field is parsed regardless of the format. It might be worth making that explicit in the docs as well.
That’s correct. I’m tempted to leave it undocumented, as I don’t want to commit to this behavior. It’s the best way to obtain a PhoneNumber for now, but maybe there will be optimized helpers in the future that do not validate the phone number, or a good reason to change that behavior. I would rather avoid giving some guarantee for implementation details if that can be avoided.
from django-phonenumber-field.
It makes sense to not want to commit to particular behavior. Unfortunately the current behavior is already being relied upon. Anyone who changes these variable with a database running is dependent upon the current behavior of flexible parsing. Changes to the parsing behavior will probably need to be documented (or else result in some nasty surprises).
Regardless, this information:
- Moving from an extension-compatible format to "E164" or NATIONAL
- changing from PHONENUMBER_DB_FORMAT="NATIONAL" and changing PHONENUMBER_DEFAULT_REGION
was very useful to me, and would probably be useful to other users who find that they need to change the db format. In my case it was to support extensions. I saw you were considering changing the default format to support extensions which would avoid cases like mine. I think that's a good idea!
from django-phonenumber-field.
Related Issues (20)
- Remove check for .mo files
- Form field does not auto-detect region from international number HOT 2
- Italian translations incomplete HOT 5
- Usage with django ninja HOT 5
- Multiple countrycodes in `PhoneNumberField` HOT 3
- Make the model/formfield region kwarg the default selection in PhoneNumberPrefixWidget HOT 1
- Validation error with wrong locale HOT 1
- bug in python 3.10 HOT 1
- [Question] Best way to generae US phonenumber for testing HOT 1
- validate_international_phonenumber does not validate correctly at some cases HOT 1
- Pydantic Serialization HOT 1
- Use Django's "normal" validation, not hardcoded in __init__() HOT 9
- Turkmenistan phone numbers has been updated HOT 1
- The valid phonenumber is not accepted by this package HOT 1
- 0493 prefix invalid numbet Australia HOT 1
- Handling of special (non-geo) phone numbers
- python-phonenumbers should be a requirement HOT 1
- django-phonenumber-field[phonenumberslite] requires phonenumbers on migration HOT 1
- Support numbers as phone numbers
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from django-phonenumber-field.