Closed Bug 118665 Opened 23 years ago Closed 2 years ago

Allow multiple email addresses / phone & fax numbers / URLs per card

Categories

(MailNews Core :: Address Book, enhancement, P3)

Product:
MailNews Core
Component:
Address Book
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 469209

People

(Reporter: BenB, Unassigned)

References

(Blocks 5 open bugs,
URL
)

Details

(Whiteboard: [gs][see comment #84 for status]) 

It might be good to have the ability to enter any number of email addresses per
person (address book card), with an optional description.

Same might apply to other fields like telephone numbers and URLs, but then
again, email addresses, phone numbers, fax numbers etc. are all just URLs,
right? :-)
Lotus Organizer has a nice way of doing it: 2 private, 2 work, 1 "other". But
Bens idea is even better: Ally the user to define *any* number of addresses and
give a *custom* description to each one. :)

Ben: How about requesting/suggesting a TM via keyword: "mozilla0.9.9"?
> How about requesting/suggesting a TM via keyword: "mozilla0.9.9"?


I have no urgent need for this. (Partly because I don't use Mozilla's address
book as my main address book holding phone numbers.) This might be a larger
change - I wouldn't suggest anything before 1.0.
Whiteboard: nab-card
*** Bug 123632 has been marked as a duplicate of this bug. ***
Dup bug requests more than 2 email addresses. This means, Composer's
autocomplete has to iterate over the list and be able to autocomplete to the
mailto: urls. We could remove "alternate email address" then.
adding self to cc list
mass re-assign.
Assignee: racham → sspitzer
This is definitely a key feature, b/c at work we all log into any of about 6
computers depending on where we are ... and as they all have builtin MTAs ... we
end up with 6 different email addresses, which all dot-forward to the same
place, but endup cluttering up the addressbook, when it auto adds them.
Yes, this would be perfect!
"Do it, finish the Job!"
 -- Homer Simpson
*** Bug 147839 has been marked as a duplicate of this bug. ***
I think Outlook Express does this perfectly.  You can add as many email address
as you like and select the default for a given contact from a list.  Please look
at OE 6 or the WAB or whatever it is called to see what I am talking about.

One of the FEW places OE is actually better than Mozilla Mail.
*** Bug 222195 has been marked as a duplicate of this bug. ***
Depends on: 228715
Flags: blocking-aviary1.0?
Flags: blocking-aviary1.0?
restoring nomination.
Flags: blocking-aviary1.0?
Flags: blocking-aviary1.0? → blocking-aviary1.0-
Product: Browser → Seamonkey
Flags: blocking-aviary1.1?
Keywords: helpwanted
Depends on: 85344
Assignee: sspitzer → mail
Assignee: mail → nobody
Component: Address Book → MailNews: Address Book
Product: Mozilla Application Suite → Core
QA Contact: nbaca → addressbook
Summary: Allow n email addresses / phone numbers / URLs per card → Allow n email addresses / phone & fax numbers / URLs per card
No longer depends on: 228715
*** Bug 228715 has been marked as a duplicate of this bug. ***
*** Bug 312054 has been marked as a duplicate of this bug. ***
Bug 312054 was marked as duplicat of this. For me there is one very important 
feature in addressbook: A second fax-field for business-fax, equal to the phone-
fields. This sould be solved in a short time.

More phone- or fax-numbers are exaggerate.

Concerning the email addresses I prefer the doing of Outlook Express.
See: Additional Comment #10 From Chris Pickett

 
*** Bug 233144 has been marked as a duplicate of this bug. ***
*** Bug 364529 has been marked as a duplicate of this bug. ***
This is an essential feature of making TB a primetime application.  I have been considering a move to Evolution simply because of the lack of support for this feature in TB.  In that program, you can select a description for each entered field value.  I have found the TB address book limiting in exactly this way.  Until this is implemented, I have to look for a better way to handle contacts. 
Some of my contacts have up to 6 email addresses. This feature is a deal-makers for me. I'm stuck with Kmail until this is implemented. Why is there a pager field, when Thunderbird does not have a phone dialer, yet not enough email address fields?
Just as another data point: the iPhone UI has a very elegant way of solving this problem.  
@David:
And that very elegant way of solving this problem is?
Even mail.app has a reasonable UI for this, I think. But, the bigger problem for Thunderbird is the backend work required for this feature. Both in storing the multiple addresses in the db and propagating them through all the code that's hard-wired for the various card fields, *and* in adding the ability to use multiple address fields in things like auto-complete, and all the other places where we look up or use e-mail addresses.
David, does the iPhone UI offer the same fields you can define within the OS X address book?
Yeah, sorry, I should have given more data.  I went off looking for screenshots to illustrate things, but couldn't find any.

Looking at the OS X address book again, it does have the same basic notions, and it's probably a closer fit to the TB user needs.
Depending on my needs I use the default fields the OS X address book supports but also add a lot of own fields e.g. to see the latest update or having the address of parents.

The OS X address book offers different data types which can be used to instantiate new objects. With the fix in bug 203927 we can read the OS X address book but aren't able to show any of these fields. Will this be covered by this bug or should I file a new one specifically for OS X?
I found an interesting page which shows the database schema used by Apple applications. Perhaps it can be helpful.

http://developer.apple.com/documentation/AppleApplications/Reference/SyncServicesSchemaRef/Articles/Contacts.html#//apple_ref/doc/uid/TP40001541-209327
Another program which offers similar N field functionality is the gnome-based "contacts" program.  It is essentially a front-end editor to the vCard format and seems to limit itself to the vCard spec, so it isn't as flexible as the OS X address book.

Ultimately, the current proprietary LDAP schema and mab format seem to be barriers to flexible fields like this.  As 'contacts' shows, vCard (and other flexible text-based formats) lend themselves more easily to this sort of thing.  More and more, I'm feeling like this is related to bug 282223.

http://pimlico-project.org/contacts.html
Kontact from KDE supports vCard and offers unlimited email address storage.
Flags: blocking-thunderbird3?
Product: Core → MailNews Core
Now that OSX Address book integration is pretty much working, its worth looking at this again, as the lack of being able to support more than two addresses per person is a weakness. 

The key use-case where its important for me, is that testing whether an email is in an address book is one part of a good spam filter. So people with multiple email addresses are failing the spam filter (appear to be someone I don't know).

- Mitra
 
Firefox crashed, destroying my almost-complete detailed comment on possible API for this feature. I'm not feeling too happy about it right now, so you'll have to settle with a brief overview.

The API proposal would be essentially to add two getter methods (I haven't considered setter methods yet) to nsIAbCard and respec the currently-existing related methods getting properties such that the current ones return an arbitrary, but deterministic, value, i.e. the first value for a property they find. The new ones would get properties for a specific "tag" ("label" in the OS X schema) and a method to return all ("tag", "value") tuples. The property values would be changed to "Email", etc. I haven't decided what to do about LDAP being able to have multiple values for a property but not tags (AFAIK).

nsIAbCollection::cardForProperty would obviously a return a card such that one of its properties has the specified value. cardForEmail would be obsolete and therefore removed.

I offer no opinions as to UI and to how to set stuff, or do something like change the tag at this point. 

There are also issues such as the complete destruction of backwards compatibility at this point, and the issue of how to handle the thorny issue of migration. I am also interested knowing of concerns on the sooner side of things, because I want to start worrying about this as I design my SQL schemas.

(In reply to comment #32)
> Now that OSX Address book integration is pretty much working, its worth looking
> at this again, as the lack of being able to support more than two addresses per
> person is a weakness. 

The primary issue is not "how to integrate this with the backends" but "what should the backend API look like." And we also potentially support N addresses on trunk now... just not in a standard way!
Not only more address, but the ability to send email to all of the addresses, especially when part of a distribution list. The only way to currently do this is to have a separate contact for each email address. Then TB would be nearly perfect. As it is I cannot sync with Gmail address book because of duplicate contacts.
There should be a list of e-mail addresses, fax/phone numbers etc. where one can enter any number of values and give each value some "type". I do not agree with the solution to give each value just some text type (this is something which can be found in Lotus Notes) but to give them some limited type (selectable from a fixed list like "home", "work", "cellphone", "other"). This way all values can be automatically used and grouped. I think it is a good idea to follow basic vCard attributes. See RFC 2426 tel-type.

Most users do not want to enter text types for any phone number, so they will end up with wrong data. Furthermore they will enter "Work", "Office", "bureau", "job" and more (+spelling) -- meaning all the same. You cannot use this text type for anything other but showing it to the user. What about sync, what about switching user interface to another language?

BTW: Lotus Notes lets you change the text type from some default but internally the values have fixed key names like "HomeFAXPhoneNumber". This key name does not change when you change the text in user interface, so scripts will always interpret it as "home fax phone number".

I think you should have a look at Palm Desktop. It's quite flexible and very easy to use.
I agree. Home, Office, Private Mobile, Work Mobile should be standard types and machine-understandable. In addition to that, the user should be able to enter other types manually, with custom text labels.
If there is a standard, that takes precedence, but personally, I find that the labels "Home, Office, etc." are pretty much useless.  I was just in a conversation with a gentleman about filling out telephone information on a form.  They had spots for 4 phones, with labels "home" "office" "cell" and "message."  His comment was something to the effect of "Why should I explain what those numbers are?  Some people work the late shift.  I just want them to call me at this number."  So, there is a question in my mind about the usefulness of fixed labels.

But, as I said, let a standard take precedence, if there is a good one.  For the lazy, the ten-year-old <a href="http://www.ietf.org/rfc/rfc2426.txt">RFC 2426 tel-type</a> shows:

   tel-type     = "HOME" / "WORK" / "PREF" / "VOICE" / "FAX" / "MSG"
                / "CELL" / "PAGER" / "BBS" / "MODEM" / "CAR" / "ISDN"
                / "VIDEO" / "PCS" / iana-token / x-name
        ; Values are case insensitive
There is a standard: vCard is most commonly used, e.g. for exchange of addresses to/from cell phones. vCard has special markers for "HOME" and "WORK" phone numbers, and so have most cell phone address book applications that I've seen. I also find the differentiation useful, personally, because that's what I need most of the time (with just a few cases where it does not fit, that's where the custom labels come in).
I believe we very much want this.
Flags: blocking-thunderbird3? → blocking-thunderbird3+
Priority: -- → P1
Standard8, is there an other bug that covers this kind of work (in particular, the multiple e-mail addresses)?
I also say this get implemented. Have been waiting for it for a very long time. Especially because not only do some people have more than one email address, but many people have more than one mobile phone number.
Some more thoughts. I'll leave the UI specs for clarkbw to work out (I can imagine how they would look, though), so I'll just stick with backend.

nsIAbCard would look like this:

interface nsIAbCard : nsIAbItem {
  nsIVariant getProperty(in AUTF8String name, in AUTF8String tag, in nsIVariant defaultValue);
  // etc.
  void getProperties(in AUTF8String name, out unsigned long length, [array, size_is(length)] out wstring tags, [array, size_is(length)] out nsIVariant values);

  void setProperty(in AUTF8String name, in AUTF8String tag, in nsIVariant value);
  void deleteProperty(in AUTF8String name, in AUTF8String tag);
}

In nsIAbCollection, we would get rid of cardForEmail in favor of the attribute (which would select all tags).

In terms of per-type implementations, we have some conundrums. LDAP permits multiple values, but has no standard form of tagging (to my knowledge). A similar problem appears to arise from the Windows address book and various sync sources (e.g., Palm, Google (?)). OS X supports the tagging in its schema, so there's no problem there. Finally, there's our own mork database, which we control so the bigger problem is how to implement it there.

For those implementations which do not support tagging (or multiple values), we have two options:
a. Build a local db that maps the tag values properly. This seems fragile (suppose someone inserts something in between the first and second values, we mess up the mapping).
b. Give them generic tag names like "First", "Second", etc. UI issues there, obviously.

Some other open questions:
1. What to do about stuff that shouldn't be multiple properties, like name or birthday?
2. What exactly should nsIAbCard::properties return?
> What to do about stuff that shouldn't be multiple
> properties, like name or birthday?

Many people have more than one name. Muhmad Abas, for instance, is also known as Abu Mazen. I myself have two birthdays, though they are on two different calendars and Thunderbird does not support the second calendar.

In short, personal information varies by culture and one cannot make assumptions about other cultures. Allow everything to be multiple.
Joshua, I think it's really important to get the high bang for the buck multiple items (e-mail addresses/phone #'s/screen names) working. If that's an order of magnitude easier than (or even twice as easy as) the full-blown general solution, I would argue that for TB 3.0, we should do the high bang for the buck thing.  Perhaps a new method for getting multi-valued fields, but only have that interface work/be used for a few highly targeted fields. I'd hate not to get n e-mail addresses in 3.0 because we were trying to get n of everything.
(In reply to comment #45)
> interface nsIAbCard : nsIAbItem {
>   nsIVariant getProperty(in AUTF8String name, in AUTF8String tag, in nsIVariant
> defaultValue);
>   // etc.
>   void getProperties(in AUTF8String name, out unsigned long length, [array,
> size_is(length)] out wstring tags, [array, size_is(length)] out nsIVariant
> values);

I'm concerned about calling it "tag". Maybe "label" would be better. The reason being that we're very soon hopefully going to have a property whose name is "tag". If we've got that and and an option to "tag" individual properties it could be confusing to new/extension developers.

> In nsIAbCollection, we would get rid of cardForEmail in favor of the attribute
> (which would select all tags).

I think you mean cardForPropertyAndTag or something like that?

> In terms of per-type implementations, we have some conundrums. LDAP permits
> multiple values, but has no standard form of tagging (to my knowledge). A
> similar problem appears to arise from the Windows address book and various sync
> sources (e.g., Palm, Google (?)). OS X supports the tagging in its schema, so
> there's no problem there. Finally, there's our own mork database, which we
> control so the bigger problem is how to implement it there.

I think the priority here would be to enable support full support for those that can easily manage it, i.e. local & OS X.

For LDAP we can just support our current primary & secondary email addresses for the time being.

For Palm we do the best we can - probably the same as LDAP. I don't see us hitting mass-market there.

> For those implementations which do not support tagging (or multiple values), we
> have two options:
> a. Build a local db that maps the tag values properly. This seems fragile
> (suppose someone inserts something in between the first and second values, we
> mess up the mapping).
> b. Give them generic tag names like "First", "Second", etc. UI issues there,
> obviously.

Ok, I've already covered some of this. LDAP is read-only currently so we can just "fix" the responses to UI to work as it does currently, we can work out more of the details of how to do it later I think. Most of this will be Bryan's department ;-) but having a local db may be the way we go - though that's a TB.next thing IMO.

> Some other open questions:
> 1. What to do about stuff that shouldn't be multiple properties, like name or
> birthday?

Well we could just change "Birthday" to "Date" and have labels of "Anniversary" and "Birthday". For name, we have property name of "Name", and labels of "First", "Last" etc

About the only fields I can see where we wouldn't necessarily need multiple options would be Notes and "Prefers to receive messages formatted as".

> 2. What exactly should nsIAbCard::properties return?

Where do we use it currently, do we really need it?


As has already been said, we really need this on email addresses first, and other things come along later. I'd certainly like to see a phased development:

1) Provide new function specifications, hook them up to local AB for email addresses only. For other ABs do quick hacks to hook into the existing options.

2) Migrate appropriate interfaces within MailNews for the email addresses.

3) Extend UI parts.

4) Improve other AB types.

5) Think about other fields (if time available in 3.0 period).
(In reply to comment #48)
> I'm concerned about calling it "tag". Maybe "label" would be better. The reason
> being that we're very soon hopefully going to have a property whose name is
> "tag". If we've got that and and an option to "tag" individual properties it
> could be confusing to new/extension developers.

I realized after writing the comment that "tag" wasn't the best name.

> > In nsIAbCollection, we would get rid of cardForEmail in favor of the attribute
> > (which would select all tags).
> 
> I think you mean cardForPropertyAndTag or something like that?

cardForEmail = "Get the code which has this as one of its email addresses," so I think that getCardFromProperty should (eventually) select from all the tagged properties.

> For Palm we do the best we can - probably the same as LDAP. I don't see us
> hitting mass-market there.

After digging a bit deeper, Palm is just too underpowered in this regard; the only things it tackles is phones.

> Ok, I've already covered some of this. LDAP is read-only currently so we can
> just "fix" the responses to UI to work as it does currently, we can work out
> more of the details of how to do it later I think. Most of this will be Bryan's
> department ;-) but having a local db may be the way we go - though that's a
> TB.next thing IMO.

LDAP fix = later, then.

> > 2. What exactly should nsIAbCard::properties return?
> 
> Where do we use it currently, do we really need it?

The only place it's used at the moment is within nsAbCardProperty::Copy and in nsAddrDatabase for saving off the card. Since its primary (and most likely only) use case involves saving everything off, it needs to know about labels here.

> 1) Provide new function specifications, hook them up to local AB for email
> addresses only. For other ABs do quick hacks to hook into the existing options.

I suppose by "hook up", you mean "make the UI and handle import correctly"?

> 2) Migrate appropriate interfaces within MailNews for the email addresses.
> 
> 3) Extend UI parts.
> 
> 4) Improve other AB types.
> 
> 5) Think about other fields (if time available in 3.0 period).

I think we can get the "other fields" more or less for free once email is done, modulo UI and import.

I'll be putting development work on this in my ab_rewrite repo on the bug118665 branch.
(In reply to comment #49)
> (In reply to comment #48)
> > 1) Provide new function specifications, hook them up to local AB for email
> > addresses only. For other ABs do quick hacks to hook into the existing options.
> 
> I suppose by "hook up", you mean "make the UI and handle import correctly"?

Implement the new APIs, import, and make sure the backend hooks into the existing front-end as a minimum. We can do the chunks of UI individually, but if we can get the backend in place, it'll mean we can do the UI in parallel (possibly sharing across more people as well).

> > 5) Think about other fields (if time available in 3.0 period).
> 
> I think we can get the "other fields" more or less for free once email is done,
> modulo UI and import.

Yes but again, keeping patch small for review is the aim. Doing all fields at once would create another massive patch again.
Update:

I have the nsAbCardProperty portions nearly finished (the only thing left is the getter stuff). On thinking more, I have two points about interface:

1. I'm not sure how useful getting a certain property and a certain label is over getting all the values and their labels.

2. One thing that struck me was that a method to indicate a certain label is "preferred" (esp. for email) would be useful. It's implementation is simple.

CC'ing clarkbw so he sees this bug before I get to step 3.

I should have step 1 ready for review tomorrow.
Assignee: nobody → Pidgeot18
Status: NEW → ASSIGNED
Keywords: helpwanted
Target Milestone: --- → Thunderbird 3.0b2
Yes, we do want an indicator of the default/primary item; especially for email addresses.  

I think we can fit into the current edtior UI if we just change the multiple value entries to be drop down selections with options for editing dialogs.  In the address book entry display we'll show the entries in order: default, alpha-by-label.

Here's an example UI for the contact editor - email addresses -v-

Default Email Address:
.------------------------------------------.
| moz-msg   clarkbw@example.com        | v |
'------------------------------------------'

Default Email Address:
.------------------------------------------.
| moz-msg   clarkbw@example.org        |*v*|
'------------------------------------------'
 |  work    clarkbw@exampe.com            |
 |  other   clarkbw@exampe.net            |
 |  ------------------------------------  |
 |  Edit Emails...                        |
 '----------------------------------------'

Edit Email Addresses Dialog
+-----------------------------------------------------+
| Edit Email Addresses                                |
|                                                     |
| [ Home  | v ] [ /email address/     ]  ( + Add )    |
|                                                     |
| .-----------------------------------.               |
| |  moz-msg    clarkbw@example.org   |               |
| |  work       clarkbw@example.org   |  ( Edit... )  |
| |  other      clarkbw@example.org   |  ( - Remove ) |
| '-----------------------------------'               |
|                                                     |
+-----------------------------------------------------+

Edit Email Address Modal Dialog
+-----------------------------------------------------+
| [ label | v ] [ email address to edit ]    ( Save ) |
+-----------------------------------------------------+
Depends on: 469209
One point to watch for, regarding default emails, and I'd hate to see this delay something which I think is quite important but .....

In OSX, on a mailing list you can change which email address is used. To test this

Enter two people in OSX Address Book 
Aaa Aaa Home=aaa1@aaa Work=aaa2@aaa
Bbb Bbb Home=bbb1@bbb Work=bbb2@bbb
Create a Folder Ccc and put these two people in it.
Open TB , send an email to Ccc and it should go to aaa1@aaa bbb1@bbb

Then ... In OSX Address Book
Select Ccc
Edit /Edit Distribution List
Change the address used for Bbb to bbb2@bbb

In TB, send an email to Ccc - it should go to aaa1@aaa bbb2@bbb
THanks henrik , yes - missed that, I posted it here because of the comment from Bryan above about primary/default address.
It would be great if the order in which the multiple values are returned is consistent.  It would be no good if sync clients thought that the properties had been rearranged when they hadn't.

Implementing as email1, email2, email3 would have the desired effect, or if the multi-values are returned in an array, then each value's position in the array should be consistent, unlesss the user or some software changed it.
Anyone working on this enhancement request? Any chance we could get it on 3.0b2?
Currently (TB 3.0 trunk), not even the secondary email address autocompletes. I filed regression bug 470589 about that.
(In reply to comment #48)
> (In reply to comment #45)
> > interface nsIAbCard : nsIAbItem {
> >   nsIVariant getProperty(in AUTF8String name, in AUTF8String tag, in nsIVariant
> > defaultValue);
> >   // etc.
> >   void getProperties(in AUTF8String name, out unsigned long length, [array,
> > size_is(length)] out wstring tags, [array, size_is(length)] out nsIVariant
> > values);
> 
> I'm concerned about calling it "tag". Maybe "label" would be better. 

The jargon used by vCard for this is "type" (and therefore also CardDAV, hCard and Portable Contacts).  Since the market seems to be converging around those standards, how about we use that?

> As has already been said, we really need this on email addresses first, and
> other things come along later. I'd certainly like to see a phased development:
> 
> 1) Provide new function specifications, hook them up to local AB for email
> addresses only. For other ABs do quick hacks to hook into the existing options.
> 
> 2) Migrate appropriate interfaces within MailNews for the email addresses.
> 
> 3) Extend UI parts.
> 
> 4) Improve other AB types.
> 
> 5) Think about other fields (if time available in 3.0 period).

6. Handle import/export of typed fields (though maybe you were including that under the "migrate appropriate interfaces").  

(In reply to comment #56)
> It would be great if the order in which the multiple values are returned is
> consistent.  It would be no good if sync clients thought that the properties
> had been rearranged when they hadn't.

By this, you're saying that there are a non-trivial number of sync clients that implicitly assume that such lists are ordered rather than unordered?
(In reply to comment #59)
> (In reply to comment #56)
> > It would be great if the order in which the multiple values are returned is
> > consistent.  It would be no good if sync clients thought that the properties
> > had been rearranged when they hadn't.
> 
> By this, you're saying that there are a non-trivial number of sync clients that
> implicitly assume that such lists are ordered rather than unordered?

Two issues related to ordering.

1. convenience
   It's a lot easier to compare and sync ordered lists vs
   unordered lists.  Not to mention faster.  I'm not sure
   what the complexity of an algorithm to compare two undordered
   lists is but I'm sure it's worse than O(n).

2. semantics
   even though there are n email addresses they might not all be
   created equal.  eg. in a contact summary view only one or two
   might be visible.  Or you might want to know:
   "what's fred's email address?" without bothering with labels/types.
   PrimaryEmail and SecondEmail currently serves these purposes.

Examples from other systems:
Google:
- preserves order of <email> elements within an atom <feed>
- one <email> element can have a 'primary' attribute, some
  discussion on this here:
http://groups.google.com/group/google-contacts-api/browse_thread/thread/9b4f01a2869dd394?hl=en#

Zimbra:
- has unique property names that map to the UI, ie
  email1 is the first email entered in the UI
  email2 is the second
  and so on.

So both Google and Zimbra preserve ordering, and interestingly both orderings correspond to the ordering in the UI.  How much of this is guaranteed vs luck I'm not sure.

But the upshot is that I reckon it'd be good for there to be some way of iterating over the n properties in some sort of consistent way.  Even with Thunderbird, it'd be nice if the first time UI shows the user
one@example.com
two@example.com
three@example.com
then then next time the UI shows the same thing.
BTW: The complexity of compare/sync ordered lists is O(n * log(n)) in general (when using a normal amount of memory).

There two most used orderings:

a) field types are unique: email1, email2, email3
Most PIMs of this type show those items in regular order (first email1), most of them will not shift values to close gaps (e.g. having email1 empty but email2/email3 filled). Some of these PIMs have some GUI option to show specific field (e.g. Outlook can show 4 phone numbers regardless of type).

b) field types are non-unique and can have multiple values: email, phone, fax
Some PIMs of this type can have one privileged value (pref-email, pref-phone), some have a GUI option to sort/show values freely (Palm Desktop). Nokia phones have multiple values in general and a "main phone number" (can be any phone number of any type). I guess this is very close to vCard. I would not rely on this order. Of course you do not want another order each time you open the contact, so this should be quite stable. But when you synchronise data with other systems you will probably loose the order for multiple values of the same type.

I suggest using the word "label" for text the user can freely type in to "label" a specific value. "type" is something that can be interpreted by machines (fixed type list, see vCard standard). I think "tag" is mostly used as something like "category" and often freely chooseable by a user.

As said before I think letting the user define labels freely is a bad idea because you will break automated sync tools.

For GUI design I really suggest having a look at Palm Desktop (and some other PIMs). Why create a new structure which is incompatible to all other systems? Take something similiar to vCard and fine-tune GUI based on existing GUIs.
(In reply to comment #61)
> I suggest using the word "label" for text the user can freely type in to
> "label" a specific value. "type" is something that can be interpreted by
> machines (fixed type list, see vCard standard). I think "tag" is mostly used as
> something like "category" and often freely chooseable by a user.

Having backend and front-end terminology different is something we frequently do. I'm not sure if that's what we are heading towards here.

> As said before I think letting the user define labels freely is a bad idea
> because you will break automated sync tools.

I think we should be considering the user's needs primarily - limiting to just a few specific labels restricts what they can do and I'll be willing to bet a small amount that someone would file a bug asking for custom labels.

The sync tools are the ones that need to figure out what to do with the labels they can't match. If devices don't support multiple items, then we can't do anything about it (except to encourage the manufacturers to extend their software) - we have precisely this problem with LDAP where not all databases have all fields (or all the ones we use), but we shouldn't limit the application just because of that.
Please think twice about "custom labels". Sync tools cannot classify labels automatically (you have to build a large mapping table, dependent on language,user,spelling...). vCard standard does not support this and most other PIMs do neither. Why create something proprietary here? There are some PIMs that have something like custom labels (e.g. Lotus Notes) but I personally don't know one that is usable in this regard. They often have a internal types (fixed) and you just change the GUI label. End-users are happy -- until they use (export/import/sync/...) tools to process those data.

I know this might sound arrogant to end-users: I'm quite sure that some end-users might file a feature request for custom labels, but they are not aware of consequences. The majority wants working sync. Most users will never have custom label needs if you allow enough types.

Without fixed types you will not be able to programmatically classify values (e.g. filter fax numbers).

Is there a custom label for e-mail and name as well? Why not? Are there types AND labels? You might get bad data (possible in Lotus Notes): type=email, value="my@address", label="phone number 1".
Stefan, we thought twice about it and I agree with Mark that custom labels are important. Please see comment 38 - custom labels do not preclude machine-readable ones, both are important.
(In reply to comment #60)
> But the upshot is that I reckon it'd be good for there to be some way of
> iterating over the n properties in some sort of consistent way.  Even with
> Thunderbird, it'd be nice if the first time UI shows the user
> one@example.com
> two@example.com
> three@example.com
> then then next time the UI shows the same thing.

The nsAbCardProperty implementation is stable wrt ordering of multi-valued properties, with one exception: SetPreferredValue, which swaps the two values. The mork address book implementation keeps the values ordered; I can't say for other implementations, but I would be surprised if such implementations did not stably store values.
Custom labels are a must.  The goal of the labels should be to help a person remember which number / email is for what purpose.  As soon as the standard labels don't describe well what purpose the number / email is for the purpose of labels has failed altogether.  This problem with standardized labels is and will continue to be a very common occurrence; note the BBS label.  With custom labels a person can always describe the purpose of the number / email exactly and thus the labels serve their real purpose to user, instead of the machine.
Just a data point for the discussion on predefined/user-defined labels/types - here's s what Google does.

Google supports two orthogonal concepts, exposed as:
- rel attributes
  allow the user to specify a relationship between an email address
  and some other well-known thing/concept (ie home/work)
  rel attributes are machine-readable (uris) and come from a
  pre-defined set specific to email/phoneNumber/postalAddress etc
- label attributes
  user-readable labels allow users to distinguish one <email>
  from another <email>

I suspect Thunderbird wants both these concepts too but whether jamming both these notions into one back-end data field is a good idea I'm not sure.

Google <email> elements can have either a label or a rel attribute but not both.

See:
http://code.google.com/apis/gdata/elements.html#gdEmail
http://code.google.com/apis/contacts/docs/2.0/reference.html#Elements
We're not going to block Thunderbird 3 on getting this in - however it is very much wanted.
Flags: wanted-thunderbird3+
Flags: blocking-thunderbird3-
Flags: blocking-thunderbird3+
Target Milestone: Thunderbird 3.0b2 → Thunderbird 3.0rc1
Blocks: 461644
Blocks: 499545
No longer blocks: 499545
Summary: Allow n email addresses / phone & fax numbers / URLs per card → Allow multiple email addresses / phone & fax numbers / URLs per card
Here some thoughts about the approach of those different, partially contradictory demands.

A) Number of Contact Fields
---------------------------
"Unlimited" number of fields: = nice to have.
And the backend should be prepared to handle that. (Which I think is already prepared this way with TB3.) However:

- 1st priority should be, that ALL fields used in the major competing PIM apps (MS Outlook, OSX, etc.) should be include in the standard TB AB.

- Import should be configured to smoothly import ALL fields a user  has with one of the above mentioned major PIMs.

- If that is done and only then, all other wishes and request may be approached.


B) Custom Labels
----------------
This sounds nice. However:

In order to avoid the need for future changing of structures and behaviour, as well as to avoid incompatibilities with other apps, I would make sure TB AB sticks to the standards. 

A good source for a close look would be the new vCard v4.0 Specification - presently available as IETF draft which can be seen here:

http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-09

In there, many things are defined. Also things like 'LABEL', 'TYPE', etc.
The tough part there is how to establish which constitutes a 'major' PIM. I'd certainly consider GMail to be one, and for parity with that, this entire feature would need to be implemented.
I think you have to look at three different cases.

1: A major PIM used in its DEFAULT way,
2: A major PIM used in a non-default way
3: Standards for interchange - e.g. VCARD

For example ..in OSX-AddressBook it is standard to be able to add multiple contact numbers (I think it is in pretty much any PIM) - behavior #1

Its also possible to define extra fields (Custom Labels) as they call it, but I doubt many people use it.

Gmail seems to have the same behavior.

I think the key compatability behavior is #1, and to meet the standards they work to for interchange. I think supporting this should be a priority task, as its a key weakness of TB - for example not supporting third email addresses, means that my junk filters - which look for known email addresses - break. 

Supporting Custom fields would be nice, and should be done, but I think its a lower priority.
I would like to ask that people leave advocacy comments and priority discussions out of this bug. This bug is already known to be wanted to fix; indeed, there is already work in progress done on this bug. Besides, bugzilla is the wrong place to discuss bug priorities.
(In reply to comment #73)
Can you give some (link to) info about implementation, especially about the storage changes?
(In reply to comment #74)
> (In reply to comment #73)
> Can you give some (link to) info about implementation, especially about the
> storage changes?

<http://hg.mozilla.org/users/Pidgeot18_gmail.com/ab_rewrite/bug118665/> and bug 469209.
URL: http://getsatisfaction.com/mozilla_me...
Whiteboard: nab-card → [gs]
Can we please have a status update on this one?
Blocks: 469516
Is the lack of information on this due to the changes in "mozilla messaging"?
See comment 73.
ahem/ harrumph: I am aware that just by posting ANYTHING here into 'Additional Comments', no matter what (maybe apart from "'I luv y'all', 'We're all 1' & 'All will b good') I will get bashed, flamed at, hated, at the best ignored, at the worst banned .. because it is by no means understandable why a humble user of TB asks how (and yes, Ben etc., after reading comment #73 from Dec. 2009...) come that a missing basic feature request (I am careful and intentionally not saying bug) cannot be addressed in due time?

Thank you very much for insights - whoever really can supply insights. I am requesting replies of CODERS addressing the PROBLEM DETAILS there are, and hopefully I can help. I AM NOT !! interested in politics, and do not want to have such replies. Thank you.
The backend itself does not feasibly support this feature; there is a (likely) bitrotted patch on bug 469209 that would essentially add in the necessary backend support, though not fully. On top of that bug, there is a necessity to design and implement the UI to expose this feature to the users.

If you are willing to help fix this bug, I would start by fixing up the patch on bug 469209 and driving that in. If you need help doing so, feel free to contact me via email or IRC.
Assignee: Pidgeot18 → nobody
Status: ASSIGNED → NEW
Target Milestone: Thunderbird 3.0rc1 → ---
There are already the labeled properties 'Email' and 'Additionally Email' (at least I guess that's what they're called). It seems too much of leap to me at this point to recode this into a dynamic feature a la gmail. A realistic goal for this step might be to replace 'Additionally Email' with 'Additionally Email 1' and add 'Additionally Email 2' to maybe [..] 'Additionally Email 5'. That should cover 99% of potential usage I dare say.

I am a JavaScript/ php "coder" (well and Visual Basic/ Turbo Pascal in the old days) and have never dealt with C++, but why not. I have Win7 (my main system), Ubuntu 11.04 and Mac OS X 10.6.8 at my finger tips. Which OS is most recommended for coding and compiling the TB source code?
(In reply to comment #85)
> There are already the labeled properties 'Email' and 'Additionally Email'
> (at least I guess that's what they're called). It seems too much of leap to
> me at this point to recode this into a dynamic feature a la gmail. A
> realistic goal for this step might be to replace 'Additionally Email' with
> 'Additionally Email 1' and add 'Additionally Email 2' to maybe [..]
> 'Additionally Email 5'. That should cover 99% of potential usage I dare say.

Could you keep in mind, that we are not only talking about eMails, but also additional Phone, Fax and Mobile Phone Numbers.
That would be very much appreciated.

PS: You might wanna contact the people from gContactSync. They have implemented various areas which are demanded herein.
The solution is not perfect, but the best I have found so far.
Look here: http://gcontactsync.mozdev.org/
or here: http://www.pirules.org/tikiwiki/tiki-index.php
and here: https://addons.mozilla.org/ud/thunderbird/addon/gcontactsync/

Thanks for your work.
(In reply to comment #85)
> There are already the labeled properties 'Email' and 'Additionally Email'
> (at least I guess that's what they're called). It seems too much of leap to
> me at this point to recode this into a dynamic feature a la gmail. A
> realistic goal for this step might be to replace 'Additionally Email' with
> 'Additionally Email 1' and add 'Additionally Email 2' to maybe [..]
> 'Additionally Email 5'. That should cover 99% of potential usage I dare say.

This workaround would probably lead to a number of problems: Among developers (this is just a guess, without looking at the code), it might force to verbosely query a hard-coded number of property getters rather than iterating over a dynamic list. Among users, it will lead to the workaround with hard-coded extra fields being around forever, because with (proverbially) 99% of the users content, there'll be even less incentive to properly solve this issue by introducing a dynamic list and make sure the program serves well for the remaining users.

If replacing the workaround of a single hard-coded field with a dynamic list really is too big a leap currently, I'd opt for accepting this for now and not trying to hide the issue with an even bigger workaround, until the dynamic list becomes an achievable goal.
Also may wanna consider

https://nic-nac-project.org/~kaosmos/morecols-en.html
version 0.6.4 (at the bottom of the page, for tb3-tb5)
already has extra fields for email and others

https://addons.mozilla.org/ro/thunderbird/addon/google-contacts/
another one that seams better to me than g sync
wow, thank you so much, ovidiu: I just installed KAOSMOS MoreFunctionsForAddressBook from nic-nac-project.org - it offers EXACTLY what I was looking for; he even utilizes 'Additionally Email 1 ..5' as I proposed as a compromise for the time being. As it works for me as supposed in TB 3.1.11 I don't see a reason anymore for me to get into rather unknown territory. Maybe one of the coders familiar with the TB AB code look at Kaosmos work and see if it makes sense to integrate it into the TB AB source, or not.

Will upgrade to TB 5 now and see if Kaosmos' XT continues to work.

Thanks again :) !!! I will also activate some kind of AB online backup, maybe syncing with my gmail address via H.Ogi's Google Contacts XT (haven't decided yet).
Unfortunately the Kaosmos extension doesn't work for the problem in Comment #32, i.e. that the extra email addresses in the Mac OSX AddressBook aren't being recognised.  Kaosmos does not import those fields (I've sent email to its author). 

many many people have more than 2 emails these days, and having to add these manually as seperate contacts in TB , as well as in the Mac AddressBook is a pain.  This bug has been reported 9 years ago, and generate another 17 duplicates. 

Its time to at least have a workaround, since it sounds like the "correct" solution is never going to happen. I'd like to recommend the suggestion of Comment #85 to add the extra fixed fields, just adding a few of these fields would handle the major problem which is the inability to filter on those not-imported addresses. 

- Mitra
Paulo Kaosmos has replied in email: "since I've not a MAC OSX available, it's very unlikely that I can work on this, sorry. "
we need to send Paulo a hackintosh or a manual how to run OS X in VMWare or Vbox .. ;)
(In reply to comment #89)
> wow, thank you so much, ovidiu: I just installed KAOSMOS
...
> maybe syncing with my gmail address via H.Ogi's Google Contacts XT (haven't
> decided yet).

You're welcome, though I was hoping to help move on the bug solution.:(
You may think it's enough, but I consider not because:

1. I use this + Google contacts + nokia (ovi suite3 does tb sync)
and I always wonder if it's gonna mess any of the 3 AB (tb, google, nok)
TB is in the middle and AB is too much of a basic and big thing. So I keep them separated ... and othar triks

2.Extensions, generally, have to keep pace with tb releases and I don't think there's enough testing to rely on a whole feature like ab (I prefer to use kaosmos's for the extra copy save etc, not fields outside basic...)

3.I think you'd have lot of support from Tb team if dive in such a work. There where other experiments, like Sync for tb, that was doing a basic ab sync on a moz server just like Firefox does and others. 

I cannot do any of this work. Just sorry you dropped it for the first workaround
Please, take your discussions of these extensions out of this bug. Every time you write a comment, you are sending email to over 100 people; therefore, please only comment on the bug if you are directly involved in fixing this bug.
Whiteboard: [gs] → [gs][see comment #84 for status]
Hi,
sorry not to read the hundred of comments above.

Multiple email addresses per card is a feature that is being asked for ages and nothing seems to have been done yet to solve this problem.

It’s a bug reported 10 years ago(!!!), and this is a hindrance for many new users that can’t accept having their address book messed up by several virtual cards per physical (real) contact, as well as a considerable inconvenience for current users.

An unlimited number of the email addresses is more important than any other field, as we do use this software to send emails. 

I would like to know, what’s up on this matter? Is there any technical or other problem that prevent to fix it? Which?

That should be fixed with the highest priority IMO.

Best regards
(In reply to blop25 from comment #98)
> Multiple email addresses per card is a feature that is being asked for ages
> and nothing seems to have been done yet to solve this problem.

https://wiki.mozilla.org/Features/Thunderbird/Modern_Address_Book

I believe the Mozilla team has gotten started on the idea. That page seems quite recent as the wiki shows it was created some in 2011. Hopefully this feature gets into Thunderbird soon :)
That modern address book seems to be tracked as #744955
It would be really great to get this funtionality of arbitrary details which can be properly labeled (work, home, ...) for the details (email, phone, ...).
Since this bug has been on the list for TEN years now (and is still marked as "NEW") it clearly is never going to get fixed. 

Is there any chance that someone could at least include a patch that increases the maximum number of email addresses to four, come on, please beg , beg, beg it must just be a constant somewhere in the code. Its screwing up incoming mail filters because these people ARE in my osx address book, but TB doesn't acknowledge it.
howdy Mitra Ardron

take a look at https://bugzilla.mozilla.org/show_bug.cgi?id=118665#c88, please.

take care,
lee
Please see Comment #90, Kaosmos's extension doesn't do the job since it doesn't recognize the OSX addresses on import which is the key problem behind this bug.
howdy Mitra Ardron,

please accept my apology for not understanding your request for OSX address book integration. i got stuck on the "more email addresses" part. [*blush*] still, better OSX address book integration  seems more of an item for another bug.

take care,
lee
Lee - thanks, but the point is that the reason for my post (and some of the commenters have other needs) is that without extra email addresses there is nowhere for the existing (and functioning well) OSX integration to put stuff. Trouble with add-ons (like Kaosmos) is that they don't full integrate with the rest of TB, and at least when I looked at it before didn't work with the OSX Address-book integration built into TB.
A recent update on this type of work is available here:

http://mikeconley.ca/blog/2012/05/07/a-slight-redirection/

Please discuss any further questions on routes forward on the tb-planning mailing list.
it seems to me that all the talk of a new address book is exactly the problem ! Instead of fixing the bad bugs in the existing one they just get put off (FOR 10 YEARS) while waiting for a new one.
In general: Please read and understand comment 84 and 106 before creating bugmail by commenting or even adding off-topic meta comments about development in general. Also see the "No obligations" section of https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
Andre - Yes I have read not only the comments, but the link on Comment #106 states "We will then design an address book for Thunderbird, distinct from the Gaia Contacts app, to operate on top of the Contacts API."  which is one of the excuses used not to address the simple bug fix of increasing the number of email addresses to some other larger number which would address the issues caused by probably 95% of the 21 duplicate bugs to this posted in the last 10 years.   Bug #84 is unclear which exact feature it can't support, and I find it hard to believe that a backend couldn't trivially be extended from 2 email addresses to 4 or 6.
> and I find it hard to believe that a backend couldn't trivially be
> extended from 2 email addresses to 4 or 6.

As already stated in comment 87, I would strongly oppose such an incomplete fix. It hides the problem and makes it even less likely that it will ever get fixed properly.
It's not a trivial change if it changes the address book structure. Then you have to deal with issues of converting between the old and new format, and dataloss issues if anybody needs to convert back. And then there's the compatibility losses. If we are going to break stuff, it's better to make it so we don't need to break it again next year with another "trivial patch."
Florian's comment #110 brings to mind Voltaire's aphorism "The Perfect is the Enemy of the Good", i.e. 10 years would suggest this bug is never going to get fixed "properly' so shouldn't we patch it so at least it works 

Its the same problem as seen with the data-losing crashing bug #476541, and longstanding, fixable, repeatedly duplicated bugs like this which give TB its bad reputation for stability & bugs.
Mitra, please refrain from commenting further, as it's fruitless. (This is the third warning.) I understand - and in fact share - your frustration. But as mentioned before, you entirely misjudge the work involved here, it's not as easy as you think. Re "shouldn't we patch it": Sure, go ahead, you can attach a patch, you always have that option. But please don't make assumptions about the work involved, if you're not a developer and haven't looked at the concrete code in question. Work is already underway, please just be patient.
For me this is a Feature request, so I'm adding myself to the list. I personally would love to be able to add anniversaries, spouse names, and separate listings for business and associations. For me the label Organization is confusing when someone has a workplace, but is a member of an organization.

I'm wondering if address books will be transitioned to SQL like some other Mozilla data storage. If so, this would be the ideal time to add support for multiple fields of the same or different types.

Otherwise, I would suggest direct CSV, DAV, or VCard integration. I believe at least one of those is an XML format.

Another option would be mapping address book custom fields in prefs.js directly or via about:config until such time as it might be added to preferences.

I realize "hard coding" is necessary for URLs, but this would not be necessary for telephone numbers, relationships such as a spouse field, custom postal address fields, and other standard and custom  fields not implemented in address book.

I hope my thoughts are helpful. I'm more of an idea person than a programmer.
This request is now more than 10 years old! Come on, the world has changed. There are people out there with much more than 2 phone numbers or email addresses. Currently I am trying to sync my contacts with my phone (carddav). This just sucks, because if I edit them in Thunderbird and sync them, the Emails are gone (only the first 2 are left).
Wow, this bug report / feature request ist really old, thunderbird 17 is out and this feature is still badly needed my many people out there.
I also Agree with  Felix that people is having 2 Mobiles & Also 3 to 4 Email Addresses. 

Need Development Seriously.
(In reply to Prashant from comment #118)
> I also Agree with  Felix that people is having 2 Mobiles & Also 3 to 4 Email
> Addresses. 
> 
> Need Development Seriously.

I do have about 250 eMail addresses to receive eMails. Because I generate new eMails for almost all Logins, accounts, etc. so I know where eMail addresses leak from, and I only have to shut down the compromised ones. I own 4 domain names. And for business and personal use, I mostly use the general (info@...) and personalized (name@...) addresses plus some special ones. Resulting in 16 (in TB configured) eMail addresses, I actively use to send out eMails.

This info to give some ideas where (some) people are in todays virtual world.
Do anyone really expect Mozilla to fix this mess? I think they need all their time to programm another (useless) OS for mobile devices. Ubuntu One failed, but that doesn't matter to Mozilla Foundation.

Maybe in another 11 years, when Firefox OS will also have failed, somebody remembers to their REAL mission: make software for real users. But i'm afraid we'll have left Thunderbird 'till then ...
THis is ****.
My problem is not, that it doesn't allow to have more emails and phone numbers. It even deletes numbers and adresses from contacts synced with caldav servers! Stop it!
As we don't have caldav sync support in thunderbird, that would be a bug in whatever software/add-on you use to do the sync.
i use the inverse sogo connector, but i'm not sure, whether it really is a bug there. I would guess the connector is syncing all fields, that are supported by both endpoints of the connection. and if numbers or mail adresses are dismissed by thunderbird, it may (correctly) SYNCHRONIZE this back to the other party? But that's just a guess.
Personally, i would like to start working at this problems, but at the moment, i have no clue where to start, as the mozilla source are very complex and i need to get an overview first.
If you would like to help, the best place to start would probably be helping out Mike with Ensemble, as that is likely to form the long-term replacement for the current address book. You can read about the project here: http://mikeconley.ca/blog/category/mozilla-2/thunderbird/
Ok, I will have a look into this. Thank you.
We REALLY need this feature !... everyone has more than one email adress !... maybe someone could organize a crowdfunding to achieve this incredible miss...
(In reply to Philippe VIGNEAU from comment #127)
> !... maybe someone could organize a crowdfunding

Maybe you should!

Just an idea: replace the "votes" in bugzilla for pledges for micropayments starting from 1$/€, where the payment system is entirely handled by Mozilla, so no money is lost to intermediaries. The money collected goes to the person that fixes the bug. In case of dispute, Mozilla decides how the money should be assigned/split.
howdy y'all,

for those who missed comment 88, take a look at this extension ...
MoreFunctionsForAddressBook 
- https://nic-nac-project.org/~kaosmos/morecols-en.html

it adds a new tab ["other emails"] with 5 more email slots. it also adds all fields to the contact search. i don't know if it adds the "other emails" fields to the email address autocomplete. i suspect _not_.

it also adds a number of other fields that may prove useful.

take care,
lee
any news on officially support from mozilla?!

the add-on is nice, but no other plugin build on it (like google contact sync...), so they dont know to store/use the extra fields from "MoreFunctionsForAddressBook".
I consider a Plugin like the one suggested above an improper solution for the problem: the address book is core functionality of an email program. If you add additional email addresses (beyond the second that is currently supported) using any plugin and this plugin is abandoned, how do you have access to already added additional addresses once the plugin fails to work with new versions of the email client? Also I think that having several email addresses is so common nowadays that a limitation to 2 (or even 5) is certainly insufficient. Please add this functionality to the core, please do!

Regards,

Andreas
Kent, FYI - this must be among the most-wanted RFEs, and massively annoying our user base (22 dupes, 141 votes).

Imho, we should be very pragmatic about trying by all means foul and fair to remove such massive painpoints without waiting for the complete re-invention of the AB which just does not seem to happen any time soon.

Even if we could land some hack expanding to 5 email addreses per contact, that would reduce the problem by a factor of 2.5. Probably sufficient for many scenarios. E.g. if one contact is currently associated with 10 email addresses, users will currently have to spread these over as many as 5 (!) different contacts. With 5 addresses per contact, there would only be 2 contacts to manage.
Right Thomas, I'm aware of this and other much-requested features. We need to talk about future issues though after we get Thunderbird 38 out.
Another point why this is needed:

I have several "Saved Searches" where mails from a certain person are collected. It's defined as e.g. "Show all mails from/to bob@mail1..., bob@mail2... and bob3@mail3..."

Now when Bob has a new email address bob@mail4... there are three(!) conditions to be complied with so that this new mail address is respected in my "saved search":

1. I have to notice that Bob has a new mail address

2. I have to remember that i use a "saved search" for Bobs mails

3. I have to add Bobs new mail address to this "saved search"

Apart from the unreliable option to define the "saved search" with a more general addressbook field (Name, Displayname  Nickname), it should be possible to have a unique name for an address book entry.
(In reply to Mark Banner (:standard8) from comment #125)
> If you would like to help, the best place to start would probably be helping
> out Mike with Ensemble, as that is likely to form the long-term replacement
> for the current address book. You can read about the project here:
> http://mikeconley.ca/blog/category/mozilla-2/thunderbird/

There is "Bug 841598 - (ensemble) A new Thunderbird address book [meta]", however, the project seems effectively abandoned for lack of time. Perhaps that is not the best place to start.

(In reply to Joshua Cranmer [:jcranmer] from comment #84)
> The backend itself does not feasibly support this feature; there is a
> (likely) bitrotted patch on bug 469209 that would essentially add in the
> necessary backend support, though not fully. On top of that bug, there is a
> necessity to design and implement the UI to expose this feature to the users.
> 
> If you are willing to help fix this bug, I would start by fixing up the
> patch on bug 469209 and driving that in. If you need help doing so, feel
> free to contact me via email or IRC.

This seems again the actual status and way forward.
(In reply to Philippe VIGNEAU from comment #136)
> one solution may be here :
> https://addons.mozilla.org/fr/thunderbird/addon/cardbook/

That looks great. How are the extra fields stored? Are they in the abook.mab database or in a separate file? If the former, are .mab files modified by your addon readable by thunderbird without your addon? Does auto-completion, search, etc work?

I'm afraid of spending a lot of effort adding the extra fields, then in 5 years, a new version of Thunderbird breaks your addon, and all the extra info I added is lost (or worse, the whole address book becomes unreadable by Thunderbird).
in this addon, contacts are stored in .vcf files
+10
So, in contrast to what the screenshots suggest:
With Cardbook, there's still the possibility to have also several local address books?
How about collision resolution, especially in comparison to SOGo-Connector?
Cardbook may have lot of local (and remote) address books
Cardbook is totally independant from Sogo
On Google contact you can Save 6 or more Email Address But When it Sync. with Thunderbird Shows only 2 Contact.

Why This ?

Where the Other contact goes ?
What is the status of fixing this - very - old bug?
Right now I don't see how to even add a second email address to a contact in Address Book..

Whilst the bug been lodged 18 years ago it is ever so more needed to be resolved considering that these days it is not uncommon for a contact to feature multiple mobile phone numbers, e.g. one for work, one or more for private. Similar for email addresses, which currently allows for two that do not distinguish between work and private either.

All the missing features seem to be implemented in extension https://addons.thunderbird.net/en-US/thunderbird/addon/cardbook/ , which also has local & remote storage.

Maybe this addon could be incorporated into Thunderbird similarly to what was done with Lightning?

(In reply to github from comment #147)

Maybe this addon could be incorporated into Thunderbird similarly to what was done with Lightning?

I really agree with this. CardBook provides an excellent address book experience. It also allows me to sync my contacts with my NextCloud instance.

But Cardbook seems to be about syncing with CardDav, not about enabling better native support within TB. There's a really poor history of any TB extension going out of date - the excellent Junquilla for example which I really depended on no longer works with current TB. Essentially if an extension doesn't get incorporated into TB it shouldn't be considered an alternative.

Personally ... I wish there was a way to rip out TB's fairly poor address book, and just use the OS one - better Address book integration is one thing that makes me consider switching to OSX's mail program (which is inferior in most aspects) and given this pretty basic bug was filed 18 years ago, there is clearly noone on the TB team that has time for it (no blame there - it is all volunteers, but if there is no time to support a feature, it would be better in many ways to rip it out, and link to the OS's native support).

Priority: P1 → P3

(In reply to Mitra Ardron from comment #149)

But Cardbook seems to be about syncing with CardDav, not about enabling better native support within TB.

This is probably a misunderstanding, Cardbook also works with local storage only (no server required). It can synchronize contacts with server, but it is not required in any way.

There's a really poor history of any TB extension going out of date - the excellent Junquilla for example which I really depended on no longer works with current TB. Essentially if an extension doesn't get incorporated into TB it shouldn't be considered an alternative.

I agree, and that's why I would like to see Cardbook incorporated into Thunderbird!

Personally ... I wish there was a way to rip out TB's fairly poor address book, and just use the OS one - better Address book integration is one thing that makes me consider switching to OSX's mail program (which is inferior in most aspects) and given this pretty basic bug was filed 18 years ago, there is clearly noone on the TB team that has time for it (no blame there - it is all volunteers, but if there is no time to support a feature, it would be better in many ways to rip it out, and link to the OS's native support).

One problem is that there is no "OS address book" on Linux so there is nothing to integrate with.

Blocks: 85344
No longer depends on: 85344
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.