Should not allow duplicate contact entries in Address Book
Categories
(MailNews Core :: Address Book, 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)
Comment 3•25 years ago
|
||
Comment 10•23 years ago
|
||
Comment 11•23 years ago
|
||
Comment 12•23 years ago
|
||
Comment 13•23 years ago
|
||
Comment 14•23 years ago
|
||
Comment 15•23 years ago
|
||
Comment 16•23 years ago
|
||
Comment 17•23 years ago
|
||
Comment 18•22 years ago
|
||
Comment 19•22 years ago
|
||
Comment 20•22 years ago
|
||
Comment 21•22 years ago
|
||
Comment 22•22 years ago
|
||
Comment 23•22 years ago
|
||
Updated•22 years ago
|
Comment 24•22 years ago
|
||
Comment 25•21 years ago
|
||
Comment 26•21 years ago
|
||
Comment 27•21 years ago
|
||
Comment 28•21 years ago
|
||
Comment 29•21 years ago
|
||
Comment 30•21 years ago
|
||
Comment 31•21 years ago
|
||
Comment 32•21 years ago
|
||
Comment 33•21 years ago
|
||
Comment 34•20 years ago
|
||
Comment 37•20 years ago
|
||
Comment 38•20 years ago
|
||
Updated•20 years ago
|
Comment 39•20 years ago
|
||
Comment 40•20 years ago
|
||
Comment 41•20 years ago
|
||
Updated•20 years ago
|
Updated•19 years ago
|
Comment 42•19 years ago
|
||
Comment 43•19 years ago
|
||
Comment 44•19 years ago
|
||
Comment 45•19 years ago
|
||
Comment 46•19 years ago
|
||
Comment 47•18 years ago
|
||
Comment 48•18 years ago
|
||
Comment 49•18 years ago
|
||
Comment 50•18 years ago
|
||
Comment 51•18 years ago
|
||
Comment 53•17 years ago
|
||
Comment 54•17 years ago
|
||
Comment 55•17 years ago
|
||
Updated•17 years ago
|
Comment 57•17 years ago
|
||
Comment 58•17 years ago
|
||
Comment 59•17 years ago
|
||
Assignee | ||
Updated•17 years ago
|
Comment 60•16 years ago
|
||
Comment 61•16 years ago
|
||
Comment 62•15 years ago
|
||
Comment 63•15 years ago
|
||
Comment 64•15 years ago
|
||
Comment 65•15 years ago
|
||
Comment 66•15 years ago
|
||
Comment 67•15 years ago
|
||
Comment 68•15 years ago
|
||
Comment 69•14 years ago
|
||
Comment 70•13 years ago
|
||
Comment 72•13 years ago
|
||
Comment 73•13 years ago
|
||
Comment 74•13 years ago
|
||
Comment 75•13 years ago
|
||
Updated•8 years ago
|
Comment 76•6 years ago
|
||
(In case it isn't obvious, Alexandre indicates he won't be working on this)
Updated•5 years ago
|
Comment 77•4 years ago
|
||
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.
Comment 78•3 years ago
|
||
(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
Comment 79•3 years ago
|
||
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.
Comment 80•3 years ago
|
||
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?
Updated•2 years ago
|
Comment 81•1 month ago
|
||
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.
Comment 82•1 month ago
|
||
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.
Description
•