944275 - When exporting contacts to SIM card implement a matching and merging algorithm

Status: RESOLVED WONTFIX

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

Description

[Jose Manuel Cantera]

This bug will track the implementation of a matching and merging algorithm while exporting contacts to SIM Card:

Thre algorithm will be based on the iccContactId and on the familyName, givenName and tel number fields according to the passive matching and merging rules. Using these two criteria (iccContactId and passive matching and merging rules we will be solving in a pretty decent manner the export SIM contacts duplication.

Comment 1

[Jose Manuel Cantera]

Proposed algorithm for matching:

Let LC be a local Contact. If LC is not associated to any SIM Contact Id, then, Try to find a matching contact in the SIM Card according to the passive merge rules. 
If LC is associated to a SIM Contact Id, then retrieve the SIM Contact corresponding to that id, SC. 
If LC.name equals to SC.name and any of LC.telNumber or LC.emailAddress is in SC, then the two contacts match.
If LC.name does not equal to SC.name but any of LC.telNumber or LC.emailAddress is in SC, then the two contacts match. 
If LC.name does not equal to SC.name and any of LC.telNumber or LC.email is in SC, then the two contacts do not match. A new entry will have to be created and the LC updated conveniently to reflect its association to a new SIM Contact Id. 

Proposed algorithm for merging: 

We will never lose data already present on the SIM Card. We will be always updating data.

Comment 2

[Jose Manuel Cantera]

ni Ayman to validate the proposal

Comment 3

[Jose Manuel Cantera]

(In reply to Jose M. Cantera from comment #0)
> This bug will track the implementation of a matching and merging algorithm
> while exporting contacts to SIM Card:
> 
> Thre algorithm will be based on the iccContactId and on the familyName,
> givenName and tel number fields according to the passive matching and
> merging rules. Using these two criteria (iccContactId and passive matching
> and merging rules we will be solving in a pretty decent manner the export
> SIM contacts duplication.

See the final proposed algorithm on the comment below

Comment 4

[Germán Toro del Valle (:gtorodelvalle)]

Hi guys, maybe it is me but I guess some indentation and numbering would help to really understand the algorithm :-p Would you be so kind to rephrase it, José Manuel? As I said, maybe it is too early still in Spain :-)

On the other hand (and maybe it is me again), I do not really get the difference (apart from the naming of the email properties) between:
  - If LC.name does not equal to SC.name but any of LC.telNumber or LC.emailAddress is in SC, then the two contacts match. 
  - If LC.name does not equal to SC.name and any of LC.telNumber or LC.email is in SC, then the two contacts do not match.

Comment 5

[Wilfred Mathanaraj [:WDM]]

land when ready

Comment 6

[Noemí Freire (:noemi)]

Adding to backlog to be properly prioritized.
ni to Omega to know UX input here (please refer to comment 1 and comment 4). Thanks!

Comment 7

[Omega Feng [:Omega] [:馮於懋]]

I have the same question as German. I cannot tell the difference between:
- If LC.name does not equal to SC.name but any of LC.telNumber or LC.emailAddress is in SC, then the two contacts match. 
- If LC.name does not equal to SC.name and any of LC.telNumber or LC.email is in SC, then the two contacts do not match.

@Jose, could you explain this?

Comment 8

[Jose Manuel Cantera]

(In reply to Omega Feng [:Omega] from comment #7)
> I have the same question as German. I cannot tell the difference between:
> - 
> - 
> 
> @Jose, could you explain this?

Let me rewrite a bit: 

If LC.name does not equal to SC.name but either LC.telNumber or LC.emailAddress is in SC, then the two contacts match. 
If LC.name does not equal to SC.name and LC.telNumber neither LC.email are in SC, then the two contacts do not match.

Does it clarify?

Comment 9

[Omega Feng [:Omega] [:馮於懋]]

ni? Carrie since she's back from PTO.

Comment 10

[Carrie Wang [New account: [e-mail]]]

comment 8 looks fine to me. Thanks!

Comment 11

[Germán Toro del Valle (:gtorodelvalle)]

Setting this bug as unassigned since I am not working on it so someone can take if it still apply :( Does it, José Manuel? Maybe it can directly close as WONTFIX :)

Comment 12

[Jose Manuel Cantera]

let's keep this in the backlog

Comment 13

[BMO Automation]

Firefox OS is not being worked on