Closed Bug 917674 Opened 6 years ago Closed 6 years ago

[Contacts] Passive matching and merging when SIM contact's name is the same than an addressbook contact's last name


(Firefox OS Graveyard :: Gaia::Contacts, defect)

Gonk (Firefox OS)
Not set


(blocking-b2g:1.3+, b2g-v1.3 fixed)

1.3 C1/1.4 S1(20dec)
blocking-b2g 1.3+
Tracking Status
b2g-v1.3 --- fixed


(Reporter: isabelrios, Assigned: jmcf)



(Whiteboard: [u=commsapps-user c=contacts p=0])


(1 file)

191 bytes, text/html
: review+
Master 09/16 build:

1. Create a contact in the contact list with Last Name and Phone Number (i.e Last Name: Smith Phone: 123456789)
2. From SIM Card, import a contact with Name (same Name than contact's Last Name) and the same Phone Number (i.e. Name:Smith Phone: 123456789)

Since Name field in the first contact is empty, there should not be a matching.

There is a match and passive merge between the two contacts, at the end, there is a contact in the addressbook with the same Name and Last Name, and the Phone Number. Name: Smith, Last Name: Smith, Phone:123456789
Depends on: 898337
Blocks: 921977
triage: koi+ for merging wrong contacts
blocking-b2g: koi? → koi+
Assignee: nobody → gtorodelvalle
Target Milestone: --- → 1.2 C3(Oct25)
Target Milestone: 1.2 C3(Oct25) → ---
Target Milestone: --- → 1.2 C4(Nov8)
Why is this blocking? This seems like a new feature and we're way past feature freeze.
Renoming for more discussion.
blocking-b2g: koi+ → koi?

This bug depends on bug 898337 (Contacts API does not allow to search by name field) which depends on bug Bug 850430 (Contacts API: Use WebIDL, so many changes that could cause multiple regressions. Maybe at this stage of release v1.2, it would be better to defer this bug and dependencies to v1.3, asking product for his point of view here
Flags: needinfo?(wmathanaraj)
Agreed - this is a bug and it needs fixing but we can fix this in v1.3 and not in v1.2. I will 1.3? this and review and move to v1.3+ if need be.
blocking-b2g: koi? → 1.3?
Flags: needinfo?(wmathanaraj)
Target Milestone: 1.2 C4(Nov8) → ---
triage: 1.3+
blocking-b2g: 1.3? → 1.3+
Target Milestone: --- → 1.3 Sprint 5 - 11/22
Duplicate of this bug: 902244
Hi Ayman, I decided to include our discussion as a comment in this bug just in case anyone wants to comment on this ;-)

So, to put the problem straight, the thing is that contacts stored in the SIM card only have a single property called "name" to deal with names whereas in Firefox OS we deal with "given name"s and "last name"s. An important aspect here is that in Firefox OS we also have the property 'name' for contacts. To this regard:

"The name property is 'fn' and can be entered by users. The 'name' property is the replacement for 'fn' (formatted name) from vCard/hCard. This is an explicit renaming (to 'name') that multiple parties have independently done (decentralized convergent evolution, the one exception being DAP which called it 'displayName'), and thus is being adopted in hCard 2 and thus we are adopting as well in the ContactsAPI."

Obviously the "translation" between 'names' and 'given and last names' is not straight forward with many locale implications. So we should try to find as general as possible.

In case you are Android users, you may be aware that their "algorithm" is pretty simple. In the sense that they offer the user a single field when creating contacts. This field can be expanded and collapsed. The algorithm "infers" the fields according to the number of words typed by the user. They use this same "algorithm" when importing contacts from the SIM card.
No need to say that if setting the ordering by last name in Android, everything is a mess according to this algorithm.

To this regard, Ayman suggested something quite similar (which is perfectly fine) as it is to consider the last word as the last name and everything in front as the given name (probably more typical from English speaking countries). Anyhow, this causes conflicts when importing contacts from the SIM card:
  - 1 word cases: Imagine a contact in the device created only with a "last name" "Simón" and another contact in the SIM card with "name" "Simón". What do we do when importing this contact from the SIM (is it a given name or a last name)? Should they match? In fact, the contact in the SIM card could be the same contact in the device previously exported to the SIM.
  - 2 word cases: Imagine 3 contacts in the device with: 1) given name: "Martín Gonzalo", 2) given name: "Martín", last name: "Gonzalo", 3) last name: "Martín Gonzalo", and another contact in the SIM card with "name" "Martín Gonzalo". Should this contact match any of the already existent in the device?, which ones?

This gets even worse as we include more words :-)

So, a possible simple solution to the problem could be (recall that we are dealing with passive matching here so at least one phone number or the email address match):

  1.- When importing contacts from the SIM card with 1 word names, assign the name to the given name. Only match contacts already in the device with the very same given name. If last names do not match, the contacts do not match and 2 distinct contacts will appear in the device.
  2.- When importing contacts from the SIM card with more than 1 word names, assign the last word to the contact last name and the rest to the contact given name. Only match contacts with the very same given and last names.

Obviously, this "algorithm" can cause previously exported to SIM contacts not to match when importing them back to the device and some manual action (this is explicitly finding duplicates (i.e., active merging)) will be needed by the user.

What do you think? Comments are more than welcome.
Flags: needinfo?(aymanmaat)
Hi all,

I would avoid trying to match a single field contact into given and surname, since the logic will be quite complex and I would say almost impossible to have something that is reliable (way to many possibilities, cultural differences, etc.)

With that said, I don't see that bad that we are not able to match absolutely everything, looking at other platforms we are quite far better than them.

Also regarding the problem of export to the sim and then import back, Jose Manuel already commented me that there is a way of fixing this by honoring the id that we receive from the contact once we import it.

removing ni? to me ...for now. Jose has a proposition which he will outline in due course. Lets pick up the conversation again when he has done that and move forwards from there.
Flags: needinfo?(aymanmaat)
+1 to Mr. Jordano. 100% agreed :-) The point is how we show to the user a contact imported from the SIM card where we only have the name field. Should we go for a only 1 field name (no distinct given and last name but just name) as Android currently does?

I guess the bugs Ayman refers to are bug 944275 and bug 944575. I will contact José Manuel about them.

So, another point would be how to deal with contacts exported to the SIM using any other platform (not a Firefox OS device) in which case we may only have the name field 'to disambiguate'. I do agree with Francisco regarding the fact that we should not aim to match absolutely everything, but we need some guidelines for these cases.
Assignee: gtorodelvalle → jmcf
Target Milestone: 1.3 Sprint 5 - 11/22 → 1.3 C1/1.4 S1(20dec)
Attached file 14712.html
r? Germán, as he knows the contacts matching and merging module. Owner and other peers are welcome on comments as well
Attachment #8348079 - Flags: review?(gtorodelvalle)
Comment on attachment 8348079 [details]

Looking good to me ;-)

After a lot of testing other issues arose but not related to this bug and its proposed patch so I will file new bugs to deal with these new issues.

Attachment #8348079 - Flags: review?(gtorodelvalle) → review+
Closed: 6 years ago
Resolution: --- → FIXED
Uplifted 241d2237e2c4f5876d0ef3ec3906b993e39dbdd7 to:
v1.3: f7111affb2b7f990b9adef073a4c66fee8a6aef9
Verified on latest buri 1.3 build (01/08):


Now it is working as expected, after importing from SIM, the contact appears on contact list with Last name, as it was created manually, and the phone number. The name coming from the SIM is discarded.
You need to log in before you can comment on or make changes to this bug.