Open Bug 45946 Opened 24 years ago Updated 1 month ago

Should not allow duplicate contact entries in Address Book

Categories

(MailNews Core :: Address Book, defect)

Product:
MailNews Core
Component:
Address Book
Type:
defect

Tracking

(Not tracked)

People

(Reporter: skasinathan, Unassigned)

References

(Blocks 3 open bugs,
URL
)

Details

User Story

https://support.mozilla.org/en-US/questions/992384
https://support.mozilla.org/en-US/questions/995641
https://support.mozilla.org/en-US/questions/1045750
https://support.mozilla.org/en-US/questions/1101514
https://support.mozilla.org/en-US/questions/1125191
https://support.mozilla.org/en-US/questions/1170594
https://support.mozilla.org/en-US/questions/1223120

Attachments

(2 files)

Test by klymax (1)
36.12 KB, image/jpeg
Details
Test by klymax (2)
33.18 KB, image/jpeg
Details 
I'm not sure what's the primary key for AB. (email ?). We should not allow
duplicate entries in AB.

Build and platform:
Today's commercial build on all three platforms.

Note: Looks like e-mail is the primary key for AB in 4.x.
nominating for nsbeta3.
Keywords: nsbeta3
QA Contact: lchiang → esther
reassigning to chuang.
Assignee: putterman → chuang
Mail triage is marking nsbeta3-
Whiteboard: [nsbeta3-]
Target Milestone: --- → Future
QA Contact: esther → pmock
*** Bug 64032 has been marked as a duplicate of this bug. ***
*** Bug 64032 has been marked as a duplicate of this bug. ***
*** Bug 46050 has been marked as a duplicate of this bug. ***
QA-assign-to fenella.
QA Contact: pmock → fenella
Summary: Do not allow duplicate entries in AB → Should not allow duplicate entries in AB
QA Contact: fenella → nbaca
reassigning to cavin
Assignee: chuang → cavin
*** Bug 107049 has been marked as a duplicate of this bug. ***
*** Bug 109769 has been marked as a duplicate of this bug. ***
I would not define any primary key. E.g. sometimes a whole family has one email address only but you want an address book entry for every single fam. member. Therefor it would be nice to perhaps display a warning message (which one can disable) - "The email address foo@foo.bar is already in the entry xxxxx yyyy" - but let the user add the entry nevertheless.

RFE -- duplicate alert should have "advanced tab/option" to view duplicates.

It would be nice if advanced feature would allow use to view contents of all
duplicate entries and allow user to manage/modify all entries _AT_SAME_TIME.

-GA
*** Bug 81543 has been marked as a duplicate of this bug. ***
Should not allow duplicates via drag-n-drop, copy or just manually adding an entry.
Whiteboard: [nsbeta3-] → [nsbeta3-],nab-card
*** Bug 118383 has been marked as a duplicate of this bug. ***
*** Bug 130613 has been marked as a duplicate of this bug. ***
*** Bug 157843 has been marked as a duplicate of this bug. ***
My problem is that I don't want the "Collected Adresses" group to show the
people I already have in my "Personal Address Book". Should I track this bug or
open a specific one?

Thanks.
please reference bug #104863.
I agree: This could even be smart, somehow indicating when the right button
context menu is pressed (showing "Add to address book...") that an entry is
already present for that email address.
status? this 'bug' has been around since 2000... !flame
this issue is still open as of:
Mozilla 1.3a
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021212
*** Bug 204654 has been marked as a duplicate of this bug. ***
Summary: Should not allow duplicate entries in AB → Should not allow duplicate entries in Address Book
I didn't find this earlier and posted bug #204654, an enhancement request.

As stated there, the question of whether an address is a duplicate or not ought
to depend on the address, not the name or "screen name". At present, addresses
without names accumulate due to the use of things like mailto links, but may
match addresses associated with names. The addressbook module doesn't recognize
this. It also thinks that names in quotes are different from names without
quotes. It also thinks that addresses are different if the case of one or more
characters is different. Nameless addresses that match addresses associated with
names ought to be discarded. Ability to run this discarding operation on an
existing address book would be nice.
yep my email adds duplicate entries. this happens when i add someone to a
mailing list i get an additional entry in my address book. For instance i have a
person on two committees, a departmental list and two other lists. He is listed
originally in my address book but since adding him to my lists i now have 5
entries for him. Isn't it possible to just place a pointer in each mailing list
to the original entry?
I believe my problem is related to this one.
To create duplicate entries...
1) Add e-mail address to Address Book.  (ex.  Name "Johny", Email "jsm@xyx.com") 
2) e-mail "Johny" and have "Johny" reply.
3) Suspose "Johny" replys and his profile is setup as
   "Smith, John"  jsm@xyx.com
4) Reply to "Johny"'s reply.
5) A new Address book entry is added with Name "Smith, John", Email "jsm@xyx.com")

I don't want a new entry for "jsm@xyx.com".  I want to keep the one I have and
leave the name as "Johny".
I suppose this >3 yr. old bug has been forgotten, or is someone working on the
perfect patch for this? :)
*** Bug 225585 has been marked as a duplicate of this bug. ***
*** Bug 217848 has been marked as a duplicate of this bug. ***
*** Bug 206422 has been marked as a duplicate of this bug. ***
Blocks: 230158
*** Bug 234672 has been marked as a duplicate of this bug. ***
*** Bug 211622 has been marked as a duplicate of this bug. ***
*** Bug 229983 has been marked as a duplicate of this bug. ***
*** Bug 256130 has been marked as a duplicate of this bug. ***
Someone please reassign this to module owner.
No longer blocks: 230158
Blocks: 258617
-> Default contacts
Assignee: cavin → sspitzer
QA Contact: nbaca
If I may add something?

It seems to me the email address should be the index - it's unique and they
don't tend to change human owners.

I think the "add to addressbook" button you get by double-clicking on an address
should actually edit the existing addressbook entry if the address clicked on
already exists - I don't think a choice is needed: 

if (unknown email address)
 { add } else { edit }

If someone actually wants to add a new addressbook entry for an existing address
- they can explicitly enter the addressbook and manually  add a new entry from
there.
Further more, the "Additional Email" should be an alternative key.

And it should be possible to add an arbitrary number of alternative emails (not
just one).
Product: Browser → Seamonkey
We're seeing the same problem as in comment #25 - should this be logged as a
separate bug?  The result is the same (duplicate entries), the cause is not
(mailing lists instead of loose checking for duplicates).
*** Bug 286734 has been marked as a duplicate of this bug. ***
Adding address to a list should not create a duplicate entry in the address book.
Assignee: sspitzer → mail
Assignee: mail → nobody
Component: Address Book → MailNews: Address Book
Product: Mozilla Application Suite → Core
QA Contact: addressbook
Target Milestone: Future → ---
*** Bug 309520 has been marked as a duplicate of this bug. ***
No longer blocks: 258617
*** Bug 258617 has been marked as a duplicate of this bug. ***
As an alternative to outright forbidding duplicates based on some arbitrary key (name, email, whatever) it could be much easier and more sensible to simply warn people.

At the moment you can do the following:

1. Open any email
2. Right-click from address --> Add to Address Book 
3. Enter as much or as little information as you want
4. OK to add
5. Right-click from address again --> Add to Address Book
6. Fill out _again_... 
5. OK to add again. No warning, no clues, just creates duplicates.

Even having a "This email address is already in your address book, are you sure" and "This name is already in your address book, are you sure?" would be quite satisfactory as a start.

(In reply to comment #44)
> As an alternative to outright forbidding duplicates based on some arbitrary key
> (name, email, whatever) it could be much easier and more sensible to simply
> warn people.

At the same time, the biggest transgressor by volume is the feature to add addresses to the book whenever replying to an email.  I'm not sure that this removes the utility of the suggestion warnings (I'm quite in favor of that as a practical means of addressing this very old bug), but a warning does tend to go against the passive addition of new entries.

The upshot, I believe, is to make the duplicate check a bit more intelligent than a simple, "Address is already there, add again?" by using logic along the lines of, "This address is already in use by [AB contact name X]" if that name is not the one that's already in the AB.  If the name is the same as the entry, then you don't even have to ask, I don't believe; you simply cancel the re-add.  If it is different, I'd suggest a flag for saying, "Don't add a new entry for this email in the future even if the name is different".  Would solve the problem for me.
*** Bug 324320 has been marked as a duplicate of this bug. ***
In addition to not allowing duplicate email addresses in the future, how do I filter the duplicate emails that are currently in my address book? I would consider exporting to csv and reimporting after using excel to filter, but

(1) The duplicates are in the "Personal" folder, which has many subfolders/lists
(2) no headers on csv so I can't reimport
(3) Have no clue if, once there is a fix for the csv with headers is in place, if I can create a "Personal 2" folder by importing the csv and that new folder would include all of the subfolders/lists or
(4) if I attempted to delete the addresses in Personal and then imported the csv back into that if the lists would still be in sync.

This is now a major problem and I would appreciate knowing how to fix this.

Thank you.
A 7 year old bug? wow.

First, a temporary solution:

http://www.sendung.de/duplicatecontactsmanager-for-thunderbird/

A bit slow but works like a charm. However it could only processes one Address Book at a time and does not check across address books. Also you get a warning that it doesn't work good with more than 1000 addresses.

Second, my related bug:

Duplicate addresses are added based on capitalisation!

Example: I compose a msg and send to klymax@gmail.com; Klymax@gmail.com and KLYMAX@GMAIL.COM

Now we all know this will reach the same person. But results for Thunderbird with collect address on: all three are added to the address book! See attached images.

Chances are you won't do this so won't experience the problem. But I only did it to demonstrate that simply based on capitalisation, the address book don't handle this well.

Maybe Thunderbird should only deal with common letters for a start.
Attached image Test by klymax (1) — 
This is from the compose window
Attached image Test by klymax (2) — 
Results window for test
I have more than 1000 entries so unfortunately that option does not work for me.
Second, because of the sources of some of the emails, I indeed have that capitalization issue as part of the problem, so yes, thunderbird should be able to know that the 3 you presented as an example are all the same.

Looks like no one is working on this and no one seems willing to take on fixing it. How very sad. 
I have read all the above comments and would like to add my own. This bug is well over 7 years old! Sorta like my arthritis, and boy, would I like to see a cure...

Much has been written about changing email addresses - someone suggested that email addresses should be the file index because they are the only constant - not really true. What we deal with are people. Persons. Individuals. The file index ought to be based on Last Name...First name.

I use address book to store all relevant information about the individuals I deal with - phone, address, etc. The email address is just one piece of the information, and it is NOT constant. People change their email addresses like they change their underwear.

Another way I use the AB is to create groups (subfolders) for my contacts. So I'll have "Family","Clubs","Group1",Group2",etc. When I get an email change advisory from one of my contacts, I currently have to search through all possible subfolders to make the change. It would be sensible to just make the change in my Personal Address Book and have all copies contained in the various subfolders changed at the same time. This would imply that the file needs to maintain a linkage from the Master (Personal Address Book) to all the clones (Subfolders or groups)

I would like to see some user preference settings, so that the address book could be used in several different ways, depending on the users requirements.

1. Store addresses by email or name?
2. Use Personal Address Book as Master index? This would be assumed if #1 is set to "Name".

In the above scenario, if #1 was set to "NAME", right-clicking on an address would result in a pop-up dialog asking for the first/last name to be inserted. If that name was a duplication of an existing entry, the user would be asked to verify whether to add a new entry or not.


I have several people using the same email address. My address book lets me insert all those contacts whitout a problem. Next my address book is divided in several subgroups. Now one of my earlier mentioned contacts (e.g. John Doe) belongs to one group, another one with the same address (e.g. Jane Doe) belongs to a second group. After adding them in de correct groups, both groups show only one person. Everytime I try to correct the contact in the group where the reference is mistaken, the second group gets updated too.

e.g.

adding John Doe to group1
adding Jane Doe to group2
-> gives Jane Doe in both groups
correcting Jane Doe in group1 to John Doe
-> gives John Doe in both groups

Since the emailadresses are the same, for now this is no problem. But when I update something in my personal addressbook, every group gets update, which in future may not be wanted. Secondly this means the content of the groups is not fully correct and there is a loss of intelligibility.
(In reply to comment #54)
> Now one of my earlier mentioned contacts (e.g. John Doe)
> belongs to one group, another one with the same address (e.g. Jane Doe) belongs
> to a second group. After adding them in de correct groups, both groups show
> only one person. Everytime I try to correct the contact in the group where the
> reference is mistaken, the second group gets updated too.

This sounds more like bug 189895 and not this bug.
Priority: P3 → --
Whiteboard: [nsbeta3-],nab-card
Bug 399689 is a duplicate of this bug.
Summary should contain the word "contact". I cannot edit the summary.
(In reply to comment #57)
> Bug 399689 is a duplicate of this bug.
> 
As I have just commented on that bug, it is not a duplicate of this bug.
Blocks: 302086
Product: Core → MailNews Core
Um.  This bug is sooo old and the "Product" name is wrong (MailNews Core).  Should Thunderbird bugs be getting duped to this stillborn bug?  And if so, should this maybe start blocking and actual Thunderbird product?

Just wondering.
Sorry about the bug spam.  Didn't notice that this applies to other products too. :-)
I also have two separate problems with duplicates, although not necessarily due to duplicates within the address books as stated above.

The first issue is the most troublesome; someone "guesses" an email address to someone in my company, and adds in a bunch of other legitimate addresses; then when someone in the group (that had a correct to: address) replies to all, they get a bogus name/email address dumped into their collected addresses and now this alternative address comes up as first option, ahead of other ABs, including published LDAP directories.

The second issue is duplicates across ABs.  If I search for someon in the LDAP AB and send them an email, the next time I search for their name, autocomplete comes up with two options, one from LDAP and one from collected addresses (and that is in addition to other dupes with other ABs, etc.).

This issue isn't one that can be solved with duplicate cleanup within ABs, this can only be addressed at the search function, specifically autocomplete searches because they go across multiple ABs.

What I would propose is an option/interface to establish priority in the autocomplete search; a list of ABs that can be moved up/down relative to each other, and by default duplicate email addresses across the AB will be filtered out by priority.  This way we can set our corporate LDAP addresses (authoritative) as the highest priority, then my personal AB, then collected addresses last.  This may also limit the effect of duplicates within ABs if you can set one contact as "default" or highest priority within the AB.

This is not exactly the main thrust of this bug, but I bring it up here because bug 428336 was duped here.

Another possibility (although I think less useful) might be the inclusion of a hierarchy model for the results returned in auto-complete; if the autocomplete returns multiple results with the same email address, you could collapse the result to a single email address with an arrow pointing to the right giving up all the duplicate results to pick from (1. Bob Smith, 2. "Smith, Bob", 3. Bobsmith, etc.).
This should be WONTFIX. 

As comment 53 says common situations exist where several cards for only one email address are wanted. Bug 189895 and Bug 539772 are examples for this need.

Bug 271570 is the request for an unique ID independently of the email address which solves the duplicate issues.
(In reply to comment #63)
> This should be WONTFIX. 

Maybe in it is current form.

> As comment 53 says common situations exist where several cards for only one
> email address are wanted. Bug 189895 and Bug 539772 are examples for this need.

I think the dups to this bug and the issues surrounding it may be to do with a few common problems in the address book:

- Duplicating email addresses when collecting them (although this is fixed in TB 3 for local address books).
- Issues with mailing lists & email addresses.
- General issues with being able to create "duplicates" (where a duplicate is not necessarily wanted).

Therefore we'd need careful consideration before marking this as wontfix, due to the user issues surrounding it.
I would like to emphasize the problem mentioned in comment #44, this is a real annoyance and one of the main reasons I went away from TB. (I will be back as soon as this is fixed.)
The problem identified in comment #44 is actually fixed in TB3, since there is now a star next to each person's name that is highlighted if they are in your AB.

But the duplicate problem still looms quite large in my mind as one of TB's greatest problems.
I would just like to reiterate the need to easily change add on, remove erroneous addresses on the fly.  The way it is now, email addresses that are typos are hard to get out of the system.
(In reply to comment #66)
> The problem identified in comment #44 is actually fixed in TB3, since there is
> now a star next to each person's name that is highlighted if they are in your
> AB.

Another use-case:
Add a contact
Add another contact with the same information

- no warning.

I guess (untested) that when receiving an email from a known person (in the contacts) with a new email-address (e.g. changed workplace), then adding this contact would also create a duplicate of the existing one without warning.

This is how I created most of my duplicates, especially because also different notations of the same email-address resulted in "new" email adresses (e.g. "name <name@domain.com>" not the same as "name@domain.com" not the same as "NaMe|DoMain.COM" ) - this might be fixed in TB3(?)
Agreed! This is a major flaw with Thunderbird as an efficient client!

And it also seriously impairs Lists!

It’s way too easy to mess up your address books and Lists by moving names around between them-- my book now has duplicates of every name, and when I deleted the extras I found that all my Lists were empty too! 

How about if Thunderbird could merge all the duplicates or otherwise make sure that if you’re deleting duplicates, the Contact is still in the Lists they’re supposed to be on unless the Contact was totally deleted?
I also Agree with 

kaecyyalpha+mozilla@gmail.com

Same thing Happens with me Also 

Lot of Duplicate entries. Waste of Time.
Well, I don't intend to fix this whole bug. However, I'd like to work on a patch that would prevent many duplicate address cases when answering or writing to someone. Since it won't fix everything, I'll be posting my work under bug 730908. 

The idea is as follow:
Right now, the address book must be looking for a case sensitive string, while it should be looking for an insensitive one.

So, first we should look for an insensitive email address in all the AB. If found, we should either not add a new entry in the collected AB or we could also try to go further and query if the name can be found in the firstname, lastname or nickname and we should do the same thing for the lastname. I would go with the second option.

I'd like some input on this proposed idea to be sure to cover as much cases as possible without doing any overkill work.
(In reply to Alexandre Demers from comment #72)
> Well, I don't intend to fix this whole bug. However, I'd like to work on a
> patch that would prevent many duplicate address cases when answering or
> writing to someone. Since it won't fix everything, I'll be posting my work
> under bug 730908. 

This issue is bug 129393, not this bug.
It is a shame that this bug has been around meanwhile for nearly 12 years  
and - apart from some discussion - nothing has happened.
Comment 72 appears the right (pragmatic) way to go.

There is a workaround in the form of a Thunderbird extension:
https://groups.google.com/group/duplicate-contact-manager-for-thunderbird
This extension was not in best shape, but I just improved it significantly:
http://David.von-Oheimb.de/perlen/Duplicate_Contact_Manager.html
The details I give there may be used as a source of inspiration
on how to do a sophisticated comparison/matching of address book cards.
Thanks David. I've been working on other things right now and I don't have much spare time right now. However, I still intend to work on this bug. I'll be looking at your suggestion.

(In reply to David von Oheimb from comment #74)
> It is a shame that this bug has been around meanwhile for nearly 12 years  
> and - apart from some discussion - nothing has happened.
> Comment 72 appears the right (pragmatic) way to go.
> 
> There is a workaround in the form of a Thunderbird extension:
> https://groups.google.com/group/duplicate-contact-manager-for-thunderbird
> This extension was not in best shape, but I just improved it significantly:
> http://David.von-Oheimb.de/perlen/Duplicate_Contact_Manager.html
> The details I give there may be used as a source of inspiration
> on how to do a sophisticated comparison/matching of address book cards.
See Also: → 1331249
Blocks: 1331249
See Also: 1331249 →

(In case it isn't obvious, Alexandre indicates he won't be working on this)

URL: https://addons.thunderbird.net/en-US/...
User Story: (updated)
Summary: Should not allow duplicate entries in Address Book → Should not allow duplicate contact entries in Address Book

Unclear to me what this bug is about... seems like a meta about issues where duplicate contacts got created for various reasons.
Obviously a certain contact should be just once per address book.

(In reply to Magnus Melin [:mkmelin] from comment #77)

Unclear to me what this bug is about... seems like a meta about issues where duplicate contacts got created for various reasons.
Obviously a certain contact should be just once per address book.

The bug should be obvious. See also how it has been formulated on the RedHat bug tracker:

No alert information when duplicate mail addresses come out.

There is quite some demand for a solution,
resulting into various workarounds including https://github.com/DDvO/Duplicate-Contacts-Manager

This bug is just one of the many bugs that are around already for ages
while Mozilla does nothing about but "managing" them in occasional debates.

What was reported on the redhat tracker seem like a bug, that AFAIK does not exist anymore.

Managing duplicates is bug 1331249.

The question remains. What actionable item is there left for this bug?

Severity: normal → S3
See Also: → 58769
See Also: → 1898648
Blocks: tb-new-addrbook
See Also: → merge-contacts
See Also: → 1773611
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: