Closed Bug 925991 Opened 11 years ago Closed 9 years ago

[B2G][Contacts] Duplicates are not suggested for contacts that have either same first or last name

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(tracking-b2g:backlog)

RESOLVED INVALID
tracking-b2g backlog

People

(Reporter: KTucker, Unassigned)

Details

(Whiteboard: burirun2, burirun3, burirun1.3-2)

Attachments

(1 file)

Description:
Empty contacts that contain only a first name or last name that matches other contacts will not be found as duplicates.

Repro Steps:
1)  Updated Buri/Inari/Leo/Unagi to Build ID: 20131011004001
2)  Tap on the "Contacts" icon.
3)  Tap on the "+" icon to add a contact.
4)  Tap on the "Name" field and enter in "Kevin".
5)  Tap "Done".
6)  Tap on "+" and add another contact with the first name "Kevin".
7)  Tap "Done" to create the contact.
7)  Tap on the one of the contacts named "Kevin" and then tap on "Find duplicate contacts".

Actual:
No duplicate contact is found.

Expected:
Contacts with matching names should be suggested as duplicates.

Environmental Variables
Device: Buri v 1.2.0 Mozilla RIL
Build ID: 20131011004001
Gecko: http://hg.mozilla.org/releases/mozilla-aurora/rev/c8e97fd5b94d
Gaia: 79abf09f2b5b6440f43cb5ae44ef6c85c0437e8d
Platform Version: 26.0a2

Notes:
Repro frequency: 100%
Link to failed test case: https://moztrap.mozilla.org/manage/case/9857/
See attached: video clip
This issue does not occur on Leo v 1.1.0 COM RIL

Environmental Variables
Device: Leo v 1.1.0 COM RIL
Build ID: 20131001041206
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/c630289d6388
Gaia: 02b975e6ce12922928c74276ac7d19432a03f126
Platform Version: 18.1
RIL Version: 01.01.00.019.240

The functionality to find duplicate contacts wasn't implemented yet.
Sounds like a basic workflow of finding duplicates isn't working.
blocking-b2g: --- → koi?
David,

Please review as it is a new feature in 1.2
Flags: needinfo?(dscravaglieri)
Hi,

Please refer to UX spec bug 875793 for matching rules for active scenario (page 6). The implementation works as it was specified so we mark this issue as INVALID
Status: NEW → RESOLVED
blocking-b2g: koi? → ---
Closed: 11 years ago
Resolution: --- → INVALID
(In reply to Noemí Freire (:noemi) from comment #4)
> Hi,
> 
> Please refer to UX spec bug 875793 for matching rules for active scenario
> (page 6). The implementation works as it was specified so we mark this issue
> as INVALID

On a quick scan of that spec I'm seeing mention of analysis of looking at the first name & last name for discovering duplicates, which leads me to believe that this is a valid use case. So I'm reopening.
Status: RESOLVED → REOPENED
blocking-b2g: --- → koi?
Resolution: INVALID → ---
I'll hold off on the nomination though until I get more information UX how common this scenario could happen, although on a first read, this seemed possible.

UX - Can I get input on how important you think this scenario this is?
blocking-b2g: koi? → ---
Flags: needinfo?(firefoxos-ux-bugzilla)
Hi,

Following the spec only in case there is an absolute match between the first name and last name that is associated to the contact from where the 'find and merge duplicate contacts' functionality was launched and the first name and last name associated to any other contact in the contact list these contacts within the contact list that have a matching first name and last name become suggestions. ni to UX, Ayman, to confirm it.
Flags: needinfo?(aymanmaat)
Ayman wrote the spec and can clarify the expected behavior, so I'm removing the ni? for general UX as redundant. As to importance, this is a feature for 1.2 and should work as expected. I would block on it since so much work has gone into multiple features on de-duping and not fixing this would just add to the problem all over again.
Flags: needinfo?(firefoxos-ux-bugzilla)
(In reply to Noemí Freire (:noemi) from comment #7)
> Hi,
> 
> Following the spec only in case there is an absolute match between the first
> name and last name that is associated to the contact from where the 'find
> and merge duplicate contacts' functionality was launched and the first name
> and last name associated to any other contact in the contact list these
> contacts within the contact list that have a matching first name and last
> name become suggestions. ni to UX, Ayman, to confirm it.

I don't think that's the right questions to ask here - that's talking about cases where the first name & last name are known. This bug is talking about the case where only the first name is known without a last name or the last name is known without a first name. I think the questions we should be asking here is:

1. Why would or wouldn't we do any duplicate suggestions if the two contacts have the same first name & no last name?

2. Why would or wouldn't we do any duplicate suggestions if the two contacts have the same last name & no first name?
Please let's wait for Ayman to chime in here. The spec was designed and reviewed with a lot of people. Let's wait for him to clarify before we spend any additional time on this.
(In reply to Jason Smith [:jsmith] from comment #9)
> (In reply to Noemí Freire (:noemi) from comment #7)
> > Hi,
> > 
> > Following the spec only in case there is an absolute match between the first
> > name and last name that is associated to the contact from where the 'find
> > and merge duplicate contacts' functionality was launched and the first name
> > and last name associated to any other contact in the contact list these
> > contacts within the contact list that have a matching first name and last
> > name become suggestions. ni to UX, Ayman, to confirm it.
> 
> I don't think that's the right questions to ask here - that's talking about
> cases where the first name & last name are known. 

No its not, its talking about both cases. But i concede the articulation of the specification is ambiguous.

> This bug is talking about
> the case where only the first name is known without a last name or the last
> name is known without a first name. I think the questions we should be
> asking here is:
> 
> 1. Why would or wouldn't we do any duplicate suggestions if the two contacts
> have the same first name & no last name?
> 
> 2. Why would or wouldn't we do any duplicate suggestions if the two contacts
> have the same last name & no first name?

Hi All

referencing document: FFOS_MergeContacts_V1.2_20130807_V5.0
page: 06

Ok, sorry, so this situation is down to a vagueness in my articulation of the specification which has precipitated a misinterpretation. In my written illustrations I concentrated on when the the firstname and lastname fields contain content. However when i use the phrase 'absolute match' in reference to firstname and lastname i am also referring to situations where the fields contain null values. I should have been clearer and included 'all' cases in the written illustrations and not concentrated solely on the case where the fields contain content. My mistake.

So as an extension to what has already been specified: 

- A contact with the name 'Chris <null>' will pick up 'Chris <null>' as a possible duplicate from the contact list
- A contact with the name 'Chris <null>' will pick up 'Christopher <null>' as a possible duplicate from the contact list
- A contact with the name 'Chris <null>' will pick up 'Christopher Smith' as a possible duplicate from the contact list

- A contact with the name 'Christopher <null>' will pick up 'Christopher <null>' as a possible duplicate from the contact list
- A contact with the name 'Christopher <null>' will pick up 'Chris <null>' as a possible duplicate from the contact list
- A contact with the name 'Christopher <null>' will pick up 'Chris Smith' as a possible duplicate from the contact list

- A contact with the name '<null> Smith' will pick up '<null> Smith' as a possible duplicate from the contact list
- A contact with the name '<null> Smith' will pick up 'Christopher Smith' as a possible duplicate from the contact list
- A contact with the name '<null> Smith' will pick up 'Chris Smith' as a possible duplicate from the contact list

- A contact with the name 'Christopher Smith' will pick up 'Chris <null>' as a possible duplicate from the contact list
- A contact with the name 'Christopher Smith' will pick up '<null> Smith' as a possible duplicate from the contact list
- A contact with the name 'Chris Smith' will pick up 'Christopher <null>' as a possible duplicate from the contact list
- A contact with the name 'Chris Smith' will pick up '<null> Smith' as a possible duplicate from the contact list

These rules should only be applied to Active merging and should not be applied to Passive (silent) merging

nominating to koi?

ni? me if you require any further clarification.
blocking-b2g: --- → koi?
Flags: needinfo?(aymanmaat)
Wilfred, this feature is not implemented yet, do we really want that in 1.2 ?
Flags: needinfo?(dscravaglieri) → needinfo?(wmathanaraj)
triage: not blocking v1.2. move to 1.3? triage to be discussed within comms team
blocking-b2g: koi? → 1.3?
Whiteboard: burirun2 → burirun2, burirun3
triage: move to 1.4? discussio
blocking-b2g: 1.3? → 1.4?
blocking-b2g: 1.4? → ---
Flags: needinfo?(wmathanaraj)
Whiteboard: burirun2, burirun3 → burirun2, burirun3, burirun1.3-2
Adding to backlog to be properly prioritized. Thanks!
blocking-b2g: --- → backlog
blocking-b2g: backlog → ---
product input.
Status: REOPENED → RESOLVED
Closed: 11 years ago9 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: