Closed Bug 813621 Opened 7 years ago Closed 7 years ago

B2G Contacts: Applying PhoneNumberJS to Contacts DB

Categories

(Core :: DOM: Device Interfaces, defect, P1)

ARM
Gonk (Firefox OS)
defect

Tracking

()

RESOLVED DUPLICATE of bug 815833
B2G C2 (20nov-10dec)
blocking-basecamp +
Tracking Status
firefox18 --- fixed
firefox19 --- fixed
firefox20 --- fixed

People

(Reporter: borjasalguero, Assigned: gwagner)

References

Details

It's needed in order to remove PhoneNumberJS from Gaia. We need a way of storing the 'typed' phone number by the user and the normalized one.
Once we request 'Give me the contact with phone number 123123123' Gecko will apply PhoneNumberJS, being in charge of having an univocal way of managing normalized phone numbers.
Blocks: 796618
Really need more information here.

Why do we need to remove PhoneNumberJS from Gaia?

Why does this *need* to happen for V1?
Answers inline:

> Why do we need to remove PhoneNumberJS from Gaia?

In SMS App (this problem is in Call log as well) we need to update the UI with the info retrieved from Contacts API. Scenario:
- Store in Contacts App the following contact:
NAME : Jesper López
PHONE NUMBER: 612123123
- Send a SMS to a phone number 0034612123123
- SMS App needs to retrieve all info from the contact with the phone number 0034612123123

What is the problem here?
As Contacts DB does not have PhoneNumberJS applied, if I request to Contacts API with the internationalized version that I typed (0034612123123) Im gonna retrieve 0 Contacts, due to the API does not have the capability of getting the 'normalized/internationalized' version of the phone number.

How is solved currently?
We have a workaround in Gaia. Instead of request Contacts API with a filter 'equals to 0034612123123', we create all possibilities given a number with PhoneNumberJS and we request with 'contains [0034612123123,+34612123123,612123123]'. This 'hack' has some problems, due to the number ''612123123" could be part of other international number that you could have in your agenda, and we are keeping the library in SMS App, so Starting time is not optimized.

> Why does this *need* to happen for V1?
We need a common way of storing and managing phone numbers in Gecko, if we apply PhoneNumberJS to Contacts & SMS DB adding a field with the 'international/normalized phone number', we will be able to remove all workarounds in Gaia (including the whole library! ) and we are going to have a consistent an univocal way of managing normalized phone
Probably we could mark this one as duplicated, because the patch is in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=815833
(In reply to Borja Salguero [:borjasalguero] from comment #2)
> > Why does this *need* to happen for V1?
> We need a common way of storing and managing phone numbers in Gecko, if we
> apply PhoneNumberJS to Contacts & SMS DB adding a field with the
> 'international/normalized phone number', we will be able to remove all
> workarounds in Gaia (including the whole library! ) and we are going to have
> a consistent an univocal way of managing normalized phone

This does not seem enough to hold back the release of V1, and not enough of a reason to justify the risk that comes with such big and new Gecko changes at this time.

Perhaps I am not fully understanding. Vivien, can you please take a look and provide input?
If we don't have one source of truth for normalized phone numbers, we're going to create a nightmare for ourselves that will last years into the future.  Apps won't know what to expect when passing to or receiving numbers from DOM APIs.  They would have to maintain O(n-versions) normalization hacks.  Gecko won't be able to fully own normalization in the future, because that would require DB upgrades that could break existing content.

QA'ing all code that deals with phone numbers would be an O(n) problem because it would have to be repeated 100% for all apps that have to deal with them.

So, I'm strongly in favor of bb+.  If integrating this would cause us to slip release by a day, I think it would be worth it.  If it caused us to slip by, say, a month, I would feel slightly differently.  But neither is the case.
(In reply to Chris Jones [:cjones] [:warhammer] from comment #5)
> QA'ing all code that deals with phone numbers would be an O(n) problem
> because it would have to be repeated 100% for all apps that have to deal
> with them.

Actually O(n^2), because phone numbers are part of the language apps use to communicate between themselves.
If this really blocks bug 796618 then it needs to be scheduled for C2 and needs an assignee. Nominating for blocking-basecamp because it's currently blocking a C2 bug.
blocking-basecamp: --- → ?
Gregor, we talked about this in triage and decided it's at least as important as doing this for the SMS app.  Therefore we're blocking on it and giving it to you.  If you're not the best owner, please assign to nobody.  Thanks!
Assignee: nobody → anygregor
blocking-basecamp: ? → +
Target Milestone: --- → B2G C2 (20nov-10dec)
This is already fixed in bug 815833. Or do we need some additional features?
Flags: needinfo?(fbsc)
Depends on: 818507
Blocks: 811539
Closing based o #9 - If there is more work to do here other than bug 815833, please reopen.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Priority: -- → P1
Flags: needinfo?(fbsc)
Scenario with Spanish SIM Card.
- Store one Contact with 612123123
- Request to Contact API with the internationalized one:
      var options = {
        filterBy: ['tel'],
        filterOp: 'equals',
        filterValue: '+34612123123'
      };

- Call to API:
window.navigator.mozContacts.find(options);

EXPECTED: Retrieve the contact

CURRENTLY: No contact retrieved for the internationalized version of the phone number
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → RESOLVED
Closed: 7 years ago7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 815833
(In reply to Borja Salguero [:borjasalguero] from comment #11)
> Scenario with Spanish SIM Card.
> - Store one Contact with 612123123
> - Request to Contact API with the internationalized one:
>       var options = {
>         filterBy: ['tel'],
>         filterOp: 'equals',

Equal currently only checks the number you entered. 'contains' should work.

>         filterValue: '+34612123123'
>       };
> 
> - Call to API:
> window.navigator.mozContacts.find(options);
> 
> EXPECTED: Retrieve the contact
> 
> CURRENTLY: No contact retrieved for the internationalized version of the
> phone number
Depends on: 839094
You need to log in before you can comment on or make changes to this bug.