maemo.org Bugzilla – Full Text Bug Listing
|Summary:||Contact names do not resolve correctly when country code is prefixed.|
|Product:||[Maemo Official Applications] Chat & Call & SMS||Reporter:||Rashid Al-Naemi <rashid>|
|Component:||Call Application UI||Assignee:||rtcomm <rtcomm>|
|Status:||RESOLVED FIXED||QA Contact:||call-ui-bugs|
|Priority:||Low||CC:||alathbi, andre_klapper, dummy.mak, lassi.syrjala, maemo.org, mahmoud.kassem, marco, rashid|
SOFTWARE VERSION: 1.2009.42-11 EXACT STEPS LEADING TO PROBLEM: When a contact's number is prefixed with the local country code (both of us being in the same nation), the contact name does not resolve correctly. Rarely, the contact name will appear but not when they are calling but in the call log. Out of the numerous calls from contacts I have received so far, 2 names have appeared in the call log. None while the phone is ringing. Example: +974555XXXX is the number stored for the contact. While I'm in +974 and receive a call from 555XXX, only the number appears and not the contact name. As above, when I hang up 1 out of maybe 50 numbers appears in the call log as the contact name. I have no extra software installed, the phone is stock. I tried the same with all the different regional ROMs with the same result. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/532.0 (KHTML, like Gecko) Chrome/18.104.22.168 Safari/532.0
Thanks for reporting this. This bug report isn't very useful because it doesn't describe the bug well. If you have time and can still reproduce the bug, please read https://bugs.maemo.org/page.cgi?id=bug-writing.html and add a more useful description to this bug by using the template: SOFTWARE VERSION: (Settings > General > About product) EXACT STEPS LEADING TO PROBLEM: (Explain in detail what you do (e.g. tap on OK) and what you see (e.g. message Connection Failed appears)) 1. 2. 3. EXPECTED OUTCOME: ACTUAL OUTCOME: REPRODUCIBILITY: (always, less than 1/10, 5/10, 9/10) EXTRA SOFTWARE INSTALLED: OTHER COMMENTS:
SOFTWARE VERSION: 1.2009.42-11p EXACT STEPS LEADING TO PROBLEM: 1. Save a local contact with the local country code prefixed (e.g be in a country whose country code is +974 and prefix local contacts with +974) 2. Get a call from any contact who has the country code before their name. (e.g While in +974, get a call from 555XXXX whose number is saved as +974555XXXX under the contact's name) EXPECTED OUTCOME: The phone will resolve the contact name correctly and display the contact name when he is calling me. ACTUAL OUTCOME: The phone doesn't display the contact name. It treats +974555XXXX and 555XXXX as different numbers and so doesn't display the contact name. REPRODUCIBILITY: 99/100 EXTRA SOFTWARE INSTALLED: None. OTHER COMMENTS: I tried this with all the different regional ROMs with no use. The same result appeared everytime.
Are you totally sure that you have no whitespaces (" ") in the stored phone number?
*** Bug 7999 has been marked as a duplicate of this bug. ***
no whitespaces (" ") in the stored phone number at all. I can confirm it with the latest version of FW 2009.2.51-1
From your example, I gather that the phone numbers there contain 7 digits and there's no area/operator code? I.e. you see either 1234567 or +9741234567? I believe the lack of operator code could explain the bug and why only two people (possibly from the same region?) reported it so far.
We see either 1234567 or +9741234567 +974 appears when receive sms from the sender, or if the caller is using another operator outside State of Qatar.
As Lassi thought that seems to happen because in Qatar you have very short numbers (just 7 digits) and in that case we do the comparison between the full number and the short number wrong. I'm writing a fix for that, thanks for the bug report.
(In reply to comment #8) > As Lassi thought that seems to happen because in Qatar you have very short > numbers (just 7 digits) and in that case we do the comparison between the full > number and the short number wrong. > I'm writing a fix for that, thanks for the bug report. > Thank you, I appreciate it. :)
Thanks for working on a fix. How the fix will be applied, in the next PR or we can have it as a patch specifically for our case?
(In reply to comment #10) > Thanks for working on a fix. How the fix will be applied, in the next PR or we > can have it as a patch specifically for our case? Sorry, but I think it will just be in the next PR :-/ The bug is in libosso-abook that sadly is closed source. You say our case, but you are not the reporter, are you from Qatar or does this happens in other countries too?
This has been fixed in package libosso-abook 4.20100121.1+0m5 which is part of the internal build version 2010.04-8 (Note: 2009/2010 is the year, and the number after is the week.) A future public update released with the year/week later than this internal build version will include the fix. (This is not always already the next public update.) Please verify that this new version fixes the bug by marking this bug report as VERIFIED after the public update has been released and if you have some time. To answer popular followup questions: * Nokia does not announce release dates of public updates in advance. * There is currently no access to these internal, non-public build versions. A Brainstorm proposal to change this exists at http://maemo.org/community/brainstorm/view/undelayed_bugfix_releases_for_nokia_open_source_packages-002/
Setting explicit PR1.2 milestone (so it's clearer in which public release the fix will be available to users). Sorry for the bugmail noise (you can filter on this message).
(In reply to comment #6) > From your example, I gather that the phone numbers there contain 7 digits and > there's no area/operator code? Side note, for Luxembourg (+358) you will have a similar problem, landlines are as short as 6 digits (used to be 5 but these days shortest length is 6) and have no area code. Except for mobile numbers, which have an area code starting with 6 (but no leading 0), followed by 2 digits and then a user number of seemingly at least 6 digits. You'll want documents with 'plan national de numérotation' in the title at http://www.ilr.public.lu/communications_electroniques/numerotation/decis_num/index.html Do tell if no one in your team speaks French and I'll look for German and/or English versions. Note; while I am from Luxembourg, I currently do not live there, hence leaving the bug in CLOSED state as I will not be able to test for you.
Yeah, somebody told me Faroe Islands have the same problem. According to the specs for the software on the N900 we have to consider 7 digits, so the original bug report is valid while the problem with Luxembourg/Faroe Islands is different. At this point there is no real chance to change it and it would be quite different, but I pinged the people working on Harmattan so we can avoid repeating the mistake.