Version: (using KDE Devel) Installed from: Compiled sources Hi! it would be very helpful to be able to define custom types of addresses and phone numbers or have a comment field for further description. Labels like "Home" and "Home(2)" or even "Work" and "Work" are not very distinguishing. Many people have more than one phone number at home e.g. several ISDN numbers in different rooms, or a normal phone plus a mobile with an additional local number("home zone"). Also for work phone numbers there might be several like a desk phone and a central number. So a comment like "Home(Living Room)" and "Home(somewhereelse)" or "Work" and "Work(Central)" would help a lot. Same for addresses many people I know have more than one home address e.g. their normal address and ther parents address. And being able to assign phone numbers to addresses and then group them together with the related address in the contact view pane(instead of listing all that exist subsequently) would help a lot to make things clearer. Greets Michael
Hi Michael, we use the vCard format as standard storage format, so we can save only data, which are supported by this format. For this reason additional telephone or address formats aren't possible. The vCard standard supports so called X-Entries for custom types, but we can't reflect them in the GUI. Ciao, Tobias
Subject: Re: custom types for addresses and phone numbers On Friday 23 May 2003 22:40, you wrote: > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > > http://bugs.kde.org/show_bug.cgi?id=58706 > tokoe@kde.org changed: > > What |Removed |Added > --------------------------------------------------------------------------- >- Status|NEW |RESOLVED > Resolution| |WONTFIX > > > > ------- Additional Comments From tokoe@kde.org 2003-05-23 22:40 ------- > Hi Michael, > > we use the vCard format as standard storage format, so we can save only > data, which are supported by this format. For this reason additional > telephone or address formats aren't possible. The vCard standard supports > so called X-Entries for custom types, but we can't reflect them in the GUI. > > Ciao, > Tobias Hi Tobias, I just found your answer in my inbox, it must have got lost somehow. Sorry about that! But as I'd really like to make kaddressbook replace my current plain text file, I need to reply anyway:) But to the topic. I don't quite understand why you closed the report with WONTFIX? I mean that's why I made a wishlist item, and I can't see why it shouldn't be possible to implement that. Even if it's a KDE only solution, I think more flexibility is really needed here. Looking at it from a developers POV the clean solution is of course to do only what the standard supports. But I look on that problem from a users point of view, and as user I find an address book kind of useless if I e.g. can't distinct three similar looking ISDN numbers which are all just labeled "Home" because they are somehow all "Home". I will have to write down and look up that information additionally elsewhere. If the standard gives a possbility to work around that limitaion with those X-Entries, shoudn't it be tried? And I don't see why you can't reflect those X-Entries in the GUI? On the vCard side wouldn't it be possible to do the following? (Or something similar) For each address: "ADR;TYPE=home:;;Street 1;Town;;12345;" write: "X-ADR;TYPE=home:<ID>;<Address Description>;;;Street 1;Town;;12345;" to associate the address with an id and a description. Then for the phone numbers like: "TEL;TYPE=home:0123/456789" write: "X-TEL;TYPE=home:<ID>;<Phone Description>;0123/456789" to associate the phone number with a description and an address. (As usually phone numbers are tied to an address, except for mobiles where <ID> would be empty.) That gives you all compatibility to other vCard apps(as they would simply ignore X-* if I see it right) while still having additional information within KDE. Just my thoughts on that topic. Kaddressbook should IMHO be made to fit to the reality, not the other way round. Unfortunately I don't have the time to implement it myself, so I can just add a wish. Greetings Michael
I would also like to see this bug be reopened as a wishlist and not left WONTFIX. Today, some people have three mobile phone numbers. While one could create custom fields in KAddressBook, the custom fields do not have the advantages that the phone fields have. @Tobias: Please reconsider reopening this wishlist item. If you decide against it, please tell why. With Akonadi in KDE4, this should be entirely possible. Thanks.
A possible solution to this bug would be to take advantage of the vCard custom fields. For each phone number of a custom type there could be a specially-formated vCard custom field, like so: X-KADDRESSBOOK-PHONE-OrangeCellphone:123-456-7890 Note that KAddressBook currently uses this format for regular custom fields: X-KADDRESSBOOK-OrangeCellphone:123-456-7890 So simply appending "-PHONE" after "X-KADDRESSBOOK" would work. This is 100% vCard legal.
Now that Kaddressbook will be using Akonadi as the internal file format could this feature please be implemented? For export compatibility, see comment #4.
The development of the old KAddressBook will be discontinued for KDE 4.4. Since the new application has the same name, but a completly new code base we close all bug reports against the old version and ask the submitters to resend there reports against the new product.
Thanks, Tobias, I am moving this feature request to the new Kaddressbook Product.
*** Bug 224032 has been marked as a duplicate of this bug. ***
As it is already possible to distinguish between Home, Work, Mobile, and so on phone numbers, the more important part IMHO is to accomplish the same for email addresses . You can collect a lot of email addresses for one person, but you have to remember which is work, which is private to not accidentally use the wrong address.
Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.