Bug 208719

+++ This bug was initially created as a clone of Bug #110350 +++

Version:           KDE 4.x
Installed from:    Debian testing/unstable Packages
OS:                Linux

I propose a different structure for KAddressbook data, that, on my opinion, is much more flexible and effective in office usage.
The current structure seems be taken from early PIM assistants, with a very limited capacity, and a rigid structure of data (vCard).
In fact, you have a predefined number of fields where enter phone numbers/emails and whatever, with only a limited set of description for the fields (i.e. home, work, work fax, mobile...).
A program in Delphi that I've build time ago and that I find very effective has a different aproach.
a) you have unlimited number of items (telephones, e-mails, etc.) associated to a contact (master-detail tables)
b) you have a free description of the item (i.e. "wife's phone", "Rome office L2" (I use "L2" as mnemonic to indicete "second phone line"), "private e-mail", etc.
c) you have a list of "types" of item, that currently in my program is: phone, mobile, fax only, phone and fax, e-mail
d) an "additional info" field, so it can contain the IM protocol, if the item is of type IM, or the type of switch if the numeber is associated with a phone+fax (manual/automatic)
e) you can order them at will (so you put on top the more used), thanks to an "order" field

Very draft screenshot (just to give you an idea)
http://www.ammdomus.it/download/KDE/kontact_addresses_03.png

Advantages:
1) you can manage every situations, with a unlimited numbers of "items" per contact, as for people with more than one office, or with a lot of people that can be contacted but have to belong to the same contact (so you have "A.C.M.E. inc." as contact, and numbers/faxes/e-mails of the director, a pair of managers, the responsable of marketing, one secretary, an employee that is a friend of you, etc.)
2) you have separation between the number/e-mail, the description, and the "type" of technology (phone/fax/e-mail/messanger...). This greately helps when automatically dialing, or for other automatic management of these information
3) when you want to contact someone, you can filter the important info in a snap, i..e if you have to make a call, show only the rows of type "phone" or "phone and fax", if you have to send a mail, just the type "e-mail", etc., or have them showed in different color/icons
4) these data can be the base of data for a pecific telphony CRM/CTI program, with call queues, call annotations, etc. (I'm thinking about an integration with Asterisk or Yate PBX, for instance)

Disadvantages:
when you have to synch with a portable PIM (like iPaq), you don't have a 1:1 correspondence with the fields, since it uses the vCard desigh. To overcome this, there can be used multiples aproaches (the first that comes me to my mind is add one more field with "PIM sync vcard kind" that contains the old classifications, so the transfer can work with those items that have tha field that matches). In any case, the current situation is already of partial match.