Open Bug 45946 Opened 25 years ago Updated 1 month ago

Should not allow duplicate contact entries in Address Book

Categories

(MailNews Core :: Address Book, defect)

defect

Tracking

(Not tracked)

People

(Reporter: skasinathan, Unassigned)

References

(Blocks 2 open bugs, )

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)

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)

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
See Also: → merge-contacts
See Also: → 1773611

Hi,

after scanning some of the comments here, I think this should be made into a Meta-Bug.

  • Depending of the use case there are different notions of duplicate entries
  • In case of „Add this email address to the address book“, the address should be considered to be existent, if it exists.
  • In case of Bug 1929806 (IMHO wrongly closed without understanding the issue) it should be the uuid something different.

The background:
Actually two (maybe more) applications are clashing:

  • Mangaging contacts: Several contacts may share the same email address (e.g. family members). Thunderbird should support the full CardDAV standard in order to make it easy to manage Email addresses across program borders (e.g. allow managing email contacts with a smart phone)
  • Email client that is interested only in email addresses

The Address books stores addresses with an UUID as primary key, the Email client has a different storage format with different primary keys.

These two applications have overlapping scopes:

  • automatically collect email-Addresses when sending emails – here the Email should be used as the main key (not primary key) secondary keys can be names tokenised at the word boundary. If an entry is found, the email address should not be added to the address book.
  • semi-automatically collect email-addresses. The main purpose is adding unknown addresses to the address book by hand. Thunderbird correctly recognises known addresses as already in the address book
  • manually adding Email addresses: There are many cases where poeple want to have several contacts for the same email address:
    • families that use one address for all family members
    • companies that have to manage general contact, management, project partners and invoice addresses of many business partners. Some companies have separate addresses, others use one common email address (contact@example.com) for all purposes and forward the messages internally to the responsible persons (e.g. using a ticket system), in the latter case it makes sense to have several contacts with different names and phone numbers and the same email address. For business processes it make even sense to create one contact for each function if the person is not known. Such as: "Sales @ Company A" <contact@a.com>, “Invoice @ Company B" <contact@a.com> besides the entries of other companies like "Sales @ Company B" <sales@b.com>, "Invoice @ Company B" <invoice@b.com> This makes business processes much easier.
  • Collections of contacts such as mailing lists should consider the identity of the contact as their main key. If you manage a society that for example contains a mother and a son as members. You probably want to have both in the general mailing list. If both use the same email account things are a little bit more complicated:
    • the mailing list should recognise duplicate email addresses in order to avoid spamming the recipients accounts.
    • two contacts can be added if their identities differ, even if they have the same email address
      • if one contact gets removed (e.g. the mother dies or the sone moves to another country) the other one should remain in the collection
    • if one contact is added to a collection and later another contact with a different identity but the same email address is deleted from the address book, the collection should not change

I'm aware of the logical contradiction that arises from the difference between email address and identity. So some simple rules may ensure the above:

  • if only the email address is available and no user input can be done, the email must be used as only key.
  • if user input is possible, the uuid of each contact entry is the primary key, the email address can be used as secondary key. If ambiguities occur, a dialog must be presented to the user in order to select the right contact and its uuid is used as primary key.

In most cases email addresses are equipped with a name. This name can be used to improve user experiences if it uses the closest entry to the given name. For example given two contacs: a and b with address c@example.com, the header
From: a <c@example.com>
would choose the contact named a, while “b <c@exmple.com“ should be mapped to b.
This is not an equivalence measure, but a similarity. Thus, user must not rely on the automatic behaviour. But the user must always be able to correct the decision made using the similarity measure.

Such a similarity measure can be developed step by step. But it cannot guess what a user thinks. For example the three contacts:
e, f <g@example.com>,
e f <g@example.com>,
f e <g@exmaple.com>
should be treated as the same (if there is no direct match with a display name of a contact).

Only the users know what they really need. And this differs from user to user. So other means like splitting and merging of contacts are essential operations to keep the address book clean. This opens other issues in connection with subsets of address book, but this can be discussed elseware.

I forgot to mention another ambiguity:
According to the standard the addresses a@example.com and A@example.com must be considered to be different addresses. However, usually users want them to be treated as equal.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: