Issue 10574

Title
French cellular phone numbers are not valid when issued from the DOM-TOM
Priority
bug
Status
chatting
Nosy list
ced, nicoe
Assigned to
Keywords

Created on 2021-07-12.15:10:37 by nicoe, last changed 3 months ago by nicoe.

Messages

Author: [hidden] (nicoe) Tryton committer
Date: 2021-07-19.13:46:38

After some discussion it's probably best to also validate the number instead of just formatting.

Author: [hidden] (nicoe) Tryton committer
Date: 2021-07-12.17:36:42
* Cédric Krier  [2021-07-12 16:35 +0200]: 
>
>Cédric Krier <cedric.krier@b2ck.com> added the comment:
>
>On 2021-07-12 16:26, Nicolas Évrard wrote:
>> * Cédric Krier  [2021-07-12 15:28 +0200]:
>>
>> >I do not understand. We use the addresses countries only if there is no prefix
>> >on the phone.
>>
>> That's the use case: the user typed "06xxxxxxxx" without the international
>> prefix (+33 (incorrect) or +590 (correct)). It's parsed as "+33 6 xxxxxxxx"
>> (because of the address).
>>
>> If the address had been in Guadeloupe, it would have yield "+590 6 xxxxxxxx"
>> which is valid.
>
>I see no problem. The system can not guess what is the local (and there
>may be multiple local).
>We enforce to fill unambiguous number but try to guess with plausible.

So it's a won't fix because relying on is_possible_number does not work either
because it's way too easy to input invalid number with it.

The thing is that people having those phone numbers do not even realize their
phone number is not a French one. I guess they will learn it once they will
input it in something that use phonenumbers.

>> >So I do not understand why changing the address would make an
>> >existing valid phone (which has been formatted with the prefix) invalid.

Note that this is not true: a phone number that has been formatted is not
valid. It has been parsed but not validated yet.

>> The phone is not valid but parsed anyway probably because it's dialable.
>
>I do not understand what you mean.

I don't know how to be more clear than "the phone number is not valid but
parsed any way because it's dialable".

Which is how I thought phonenumbers works but after reading its code it's
false. In fact phonenumbers parse any number as long as it looks a tiny bit
valid.
Author: [hidden] (ced) Tryton committer Tryton translator
Date: 2021-07-12.16:35:04
On 2021-07-12 16:26, Nicolas Évrard wrote:
> * Cédric Krier  [2021-07-12 15:28 +0200]: 
> 
> >I do not understand. We use the addresses countries only if there is no prefix
> >on the phone.
> 
> That's the use case: the user typed "06xxxxxxxx" without the international
> prefix (+33 (incorrect) or +590 (correct)). It's parsed as "+33 6 xxxxxxxx"
> (because of the address).
> 
> If the address had been in Guadeloupe, it would have yield "+590 6 xxxxxxxx"
> which is valid.

I see no problem. The system can not guess what is the local (and there
may be multiple local).
We enforce to fill unambiguous number but try to guess with plausible.

> >So I do not understand why changing the address would make an
> >existing valid phone (which has been formatted with the prefix) invalid.
> 
> The phone is not valid but parsed anyway probably because it's dialable.

I do not understand what you mean.
Author: [hidden] (nicoe) Tryton committer
Date: 2021-07-12.16:26:07
* Cédric Krier  [2021-07-12 15:28 +0200]: 

>I do not understand. We use the addresses countries only if there is no prefix
>on the phone.

That's the use case: the user typed "06xxxxxxxx" without the international
prefix (+33 (incorrect) or +590 (correct)). It's parsed as "+33 6 xxxxxxxx"
(because of the address).

If the address had been in Guadeloupe, it would have yield "+590 6 xxxxxxxx"
which is valid.

>So I do not understand why changing the address would make an
>existing valid phone (which has been formatted with the prefix) invalid.

The phone is not valid but parsed anyway probably because it's dialable.
Author: [hidden] (ced) Tryton committer Tryton translator
Date: 2021-07-12.15:28:46

I do not understand. We use the addresses countries only if there is no prefix on the phone. So I do not understand why changing the address would make an existing valid phone (which has been formatted with the prefix) invalid.

Author: [hidden] (nicoe) Tryton committer
Date: 2021-07-12.15:10:37

Currently we're using is_valid_number to validate the phone number in the contact mechanism.

In the case of France a cellular phone which has a phone number from one of the DOM-TOM has a French-looking phonenumber but is in reality issued a number from this area (+590 instead of +33). What happens is that people move and their address is now in France.

The way we validate the phone number is by using the country code of the address of the party. And in this case it will fail because the country should be "Guadeloupe" (code 'GP').

I see different ways in which our way of validating the phone numbers this could fail:

  • the case I just explained (in which someone moved from Guadeloupe to France)
  • a user encodes someone in Guadeloupe and using "France" as the country (because they don't know they should put Guadeloupe for the phone validation to work)

I think we could use is_possible_number instead of is_valid_number. The documentation says:

  Instead of returning the reason for failure, this method returns true if
  the number is either a possible fully-qualified number (containing the area
  code and country code), or if the number could be a possible local number
  (with a country code, but missing an area code). Local numbers are
  considered possible if they could be possibly dialled in this format: if
  the area code is needed for a call to connect, the number is not considered
  possible without it.

After all if the number is diallable, it could be enough for us.

History
Date User Action Args
2021-07-19 13:46:38nicoesetmessages: + msg68930
status: invalid -> chatting
2021-07-12 17:36:58nicoesetstatus: chatting -> invalid
2021-07-12 17:36:42nicoesetmessages: + msg68843
2021-07-12 16:35:04cedsetmessages: + msg68842
2021-07-12 16:26:07nicoesetmessages: + msg68841
2021-07-12 15:28:46cedsetmessages: + msg68840
nosy: + ced
status: unread -> chatting
2021-07-12 15:10:37nicoecreate