281213 - Fields in address book editing form should be more flexible!

Status: NEW

(Thunderbird :: Address Book, defect)

Description

[Peter Aschbacher]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.5) Gecko/20041108 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.5) Gecko/20041108 Firefox/1.0

A - Every user needs different address-book fields.
So it should be possible for the user to create his own set(s) of
address-book-fields (maybe starting from given template-sets).

B - Users often need different address-book fields for different
sub-address-books. (The address-book 'Friends' needs different fields than the
address-book 'Business-Contacts').
So it should be possible to have different field-sets for different address-books.

C - Depending from a) the address-book-fields used in a specific address-book
and b) the actual address-book type every user needs a different interface in
the address-book-card-editing-dialog.

My suggestion for the address-book-card-editing-dialog interface:

Many times a contact has more than 2 email-addresses, phone numbers, URLs, etc.
So it should be possible to have any number of email-addresses, phone numbers,
URLs, addresses, custom fields, etc. for a single contact.

Contact Tab:
Instead of the Name, Internet, Phone GroupBoxes with fixed fields there should
be ListBoxes with a 'More' button and a 'Delete' button. Every item in the list
box shoud have the format [Label | Data], where the labels of course are
customizable, e.g. "Private Homepage | www.his-private-homepage.ru" or "Office
in NY | [phone]", etc. One single item in each ListBox can be marked as
'Primary'.

Addresses Tab:
The same applies to Addresses: It should be possible to add as many custom
addresses as needed for a single contact (Business, Office, OutService, Weekend,
Home, Holiday, etc.), each with any number of custom sub-fields.

Custom Fields Tab:
In the Custom Fields Tab the custom fields should also have the format [Label |
Data], where the label of course should be customizable. Only THESE custom
fields are valid through the whole address-book: If a custom field has been
created/deleted in one card then it will be available/not available in all the
other cards of the address-book. (Warning when trying to delete a custom field
already filled with data in other cards). These custom fields then should be
available as columns in the list-view of the address-book.

Settings [for this contact] Tab:
Mail Preferences (HTML, Text)
Card View Background Color
Mail-Template

Notes Tab:
The Notes tab should be a RTF control with the ability to insert RichTextFormat
and images. Drag&Drop functionality.

Reproducible: Always

Steps to Reproduce:
See above.
Actual Results:  
See above.

Expected Results:  
See above.

See above.

Comment 1

[pioterus]

I completely agree!!! For instance many of my contacts have more than two email
addresses eg. two private and a business one too. Thundirbird and Firefox are
supposed to be very customisable so such restrictions are not in the right
place. I don't need unlimited extendability but really 3 email addresses is a must.

Comment 2

[u3mozilla]

I can't say it better than the original description.

Especially true in terms of customizing the custom fields.  Also having more
than two email addresses is a must.  Having the note field be RTF control is
nice, but I prefer that we can search on it (actually on ALL the fields include
a SEARCH ALL option).

Comment 3

[Peter Aschbacher]

(In reply to comment #2)
> Having the note field be RTF control is
> nice, but I prefer that we can search on it (actually on ALL the fields include
> a SEARCH ALL option).

Of course there should be a search option which includes ALL fields!

Comment 4

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

I'm not sure how much of the improvements suggested in comment #0 have actually been implemented after all these years... How should we move this forward?

Comment 5

[Ian van Broesel]

(In reply to comment #4)
> I'm not sure how much of the improvements suggested in comment #0 have actually
> been implemented after all these years... How should we move this forward?

I'm now using version 3 and still no or only slight improvements. Seems nobody cares about the AB