991989 - [zte openc 1.3]The phone number matching rule for is not fit for peru

Status: RESOLVED FIXED

(Firefox OS Graveyard :: Runtime, defect)

Description

[zhangdapeng]

User Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; TCO_20140404084313)

Steps to reproduce:

for peru,they acquire a match rule as 7 numbers from end
that is if 7 numbers from the end is the same ,it will match 

and now it  recognize 8 numbers in the contact list

Comment 1

[Juan Perez-Bedmar [:juanpbf]]

This bug is a certification blocker. In fact, Perú is the country where we are more advanced in terms of IOT testing, and we cannot delay.

Please, help us to fix this.

Comment 2

[Gregor Wagner [:gwagner]]

We have to add in gecko/b2g/app/b2g.js
pref("dom.phonenumber.substringmatching.PE", 7);

Comment 3

[Gregor Wagner [:gwagner]]

Attachment: patch

Comment 4

[Gregor Wagner [:gwagner]]

Can you test this patch? You need a Sim card from Peru and re-import all contacts in order to enable this feature for Peru. You can also fake the country name here if you don't have the right sim card: http://hg.mozilla.org/mozilla-central/file/5fa70bd90a8b/dom/phonenumberutils/PhoneNumberUtils.jsm#l41

Comment 5

[Gregor Wagner [:gwagner]]

https://hg.mozilla.org/integration/b2g-inbound/rev/3f7bd6bed615

Comment 6

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/3f7bd6bed615

Comment 7

[Ryan VanderMeulen [:RyanVM]]

Please request approval-mozilla-b2g28? on this patch when it is ready for v1.3 uplift.

Comment 8

[Gregor Wagner [:gwagner]]

Comment on attachment 8402121 [details] [diff] [review]
patch

NOTE: This flag is now for security issues only. Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
Bug caused by (feature/regressing bug #): none
User impact if declined: Peru phone number matching doesn't work
Testing completed: up to partners
Risk to taking this patch (and alternatives if risky): none
String or UUID changes made by this patch:

Comment 9

[bhavana bajaj [:bajaj]]

(In reply to Juan Perez-Bedmar [:juanpbf] from comment #1)
> This bug is a certification blocker. In fact, Perú is the country where we
> are more advanced in terms of IOT testing, and we cannot delay.
> 
> Please, help us to fix this.

Can you try a nightly build (2.0) to confirm this is fixed for you ?

Comment 10

[Jason Smith [:jsmith]]

This is something partner QA will need to verify.

Comment 11

[Juan Perez-Bedmar [:juanpbf]]

(In reply to bhavana bajaj [:bajaj] from comment #9)
> (In reply to Juan Perez-Bedmar [:juanpbf] from comment #1)
> > This bug is a certification blocker. In fact, Perú is the country where we
> > are more advanced in terms of IOT testing, and we cannot delay.
> > 
> > Please, help us to fix this.
> 
> Can you try a nightly build (2.0) to confirm this is fixed for you ?

Our development team has locally solved this issue, by adding/modifying manually the correct configuration per country (not only Perú and Venezuela) in LATAM, in our variant.

This configuration is according to Telefonica's requirements, but I'm not sure if other operators have the same req. in those countries, or they request a different matching scheme, so I don't know if you want to uplift the code we used to the generic branches, or you prefer us (OEMs) to handle this in our respective variants.

In case you agree, please set a "ni" for my colleague Chen Cong, SW manager for our devices

Comment 12

[bhavana bajaj [:bajaj]]

:gwagner, given comment #11 are we still better-off handling this in our code-base and we should be going ahead with uplift here ?

Comment 13

[Gregor Wagner [:gwagner]]

(In reply to Juan Perez-Bedmar [:juanpbf] from comment #11)
> (In reply to bhavana bajaj [:bajaj] from comment #9)
> > (In reply to Juan Perez-Bedmar [:juanpbf] from comment #1)
> > > This bug is a certification blocker. In fact, Perú is the country where we
> > > are more advanced in terms of IOT testing, and we cannot delay.
> > > 
> > > Please, help us to fix this.
> > 
> > Can you try a nightly build (2.0) to confirm this is fixed for you ?
> 
> Our development team has locally solved this issue, by adding/modifying
> manually the correct configuration per country (not only Perú and Venezuela)
> in LATAM, in our variant.
> 
> This configuration is according to Telefonica's requirements, but I'm not
> sure if other operators have the same req. in those countries, or they
> request a different matching scheme, so I don't know if you want to uplift
> the code we used to the generic branches, or you prefer us (OEMs) to handle
> this in our respective variants.
> 
> In case you agree, please set a "ni" for my colleague Chen Cong, SW manager
> for our devices

Can we get access to these changes? If we ever perform an upgrade on those devices we need to know what the current code-path looks like or we might brick the phone.

Comment 14

[Juan Perez-Bedmar [:juanpbf]]

(In reply to Gregor Wagner [:gwagner] from comment #13)

> 
> Can we get access to these changes? If we ever perform an upgrade on those
> devices we need to know what the current code-path looks like or we might
> brick the phone.

as per above comment, I am adding needinfo to my colleague Chen Cong

Comment 15

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/bee1ba424663

Comment 16

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

Hi Gregor - 

Just attached part of the patch from ZTE for this issue, as you can see, they only add some preference setting for customizing the different number matching rule requirements of each countries/carriers.

So I think the chance to brick a device during the update is quite low

Comment 17

[Vance Chen [:vchen][skype:vance.lucida][[e-mail]]]

Attachment: Peru number matching.patch

Comment 18

[Gregor Wagner [:gwagner]]

(In reply to Vance Chen [:vchen][[e-mail]] from comment #17)
> Created attachment 8417774 [details] [diff] [review]
> Peru number matching.patch

I dont think all those exceptions are needed but the regression chance is pretty low.

Comment 19

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g28_v1_3/rev/25a318244667

Comment 20

[KTucker [:KTucker][Inactive 3/4/2016]]

Test case has been added here in Moztrap: https://moztrap.mozilla.org/manage/case/13759/