Version: (using KDE 4.3.4) Installed from: Unspecified Linux The following fields are missing from the new Kaddressbook in KDE SC 4.4: 1) Multiple IM addresses 2) Categories 3) Edit different parts of the name (for some of my contacts I only know the given name, for others only the family name) 4) Custom Fields. I am marking as a bug, not a wishlist, as this seems to be a dataloss issue. Even if the data is safely stored somewhere (I do not know if it is or if it is not, could a dev please make this clear) the user has no way to access it, so it is for him lost.
Hej Dotan, the fields will be added in later versions of KAddressBook again. As already stated in my blog entries, KAddressBook in 4.4 won't be feature complete, the main target was to get a working version based on Akonadi. Support for categories (based on Nepomuk) has already been added to trunk, more fields will follow. I can't add new fields to 4.4 branch because of string and feature freeze though. Ciao, Tobias
Is this an indication that all missing fields will be back in 4.5? Also, not sure if I should open a separate ticket for this, but custom views are also missing from 4.4. Only a small amount of fields can be selected to appear in the table (4.3 allowed any of them), and it's no longer possible to sort the table by multiple fields. Are there any plans to bring this feature back in 4.5? Thanks.
Hmmm.... Isn't Kubuntu 9.10 an LTE and going to be based on 4.4?
> Hmmm.... Isn't Kubuntu 9.10 an LTE and going > to be based on 4.4? That is a distro issue, you should either file a new bug with Kubuntu or comment on this one: https://bugs.launchpad.net/ubuntu/+source/kdepim/+bug/507990
Hi, Can you confirm there is no data loss on existing contacts? Once the fields are implemented again, the data will be there under the hood to populate? Thanks Colin.
Actually, Answered question myself. A cat of the addressbook vcf files showed the fields to still be present. Colin.
Categories have been DROPPED, and NOTHING has replaced them, and someone thought it would be OK to RELEASE!?!?!?!? Whoever is responsible should be smacked and never allowed to touch the source code again. This is an amazingly bad decision.
this is a very bad regression, I agree. please tell us how to revert to previous version and perhaps remove this package to testing or similar, the data loss is way too much. thanks.
(In reply to comment #7) > Categories have been DROPPED, and NOTHING has replaced them, and someone > thought it would be OK to RELEASE!?!?!?!? Whoever is responsible should be > smacked and never allowed to touch the source code again. This is an amazingly > bad decision. Ok, as I'm the only developer of KAddressBook and responsible for the release that means I'll shall stop working on KAddressBook and do something else? Ok, if that's what you want?... I think you should think twice before making such a stupid and inappropriate comment! Maybe you haven't realized yet, but we do this development in our spare time and we have a life next to it, studies, family etc. So instead of insulting us you should be thankful that we provide software for free! /me is seriously pissed off
Tobias, Smacking people around would not be a good thing to do. BUT - was it really necessary to include it in the release before it was finished? Isn't there a place for programs that are not finished in the KDE system? I thought that was what SVN was for. I thought people that wanted bleeding edge stuff could download an SVN snapshot and play with it. None of those people would ever complain about anything missing - the risk is implied. But when something ends up in a release version, and especially one that is marked 4.4 (waaay beyond what you call a first release - 4.4 of a software should be rock solid...), I can understand that people get frustrated. I had a lot of info in the notes field. I used the Akonadi console to try to find it. But it is not there. So I had to go back to the vcard files to find it. There was no red warnings during installation that warned "Do not proceed if you need data from the following fields in your addressbook:....". There was no alternatives offered. When it comes to e-mail and addressbooks, it is critical data. Yes, everyone should back up their data. But what does it help when you can not view your data? As the program has changed, the data is unavailable (to most people). We can not tell people "Your data will be available in a few months". If you are pissed off at the comments here, you should see someone that just have been told that the data they have spent years to gather now is unavailable for some months! We all appreciate the time you put into this. If I had any money left, I would gladly pay you to spend more time on it as I think this is the single, most important software on my computer! And as such, changes should be made very carefully. Could we please have the old addressbook back so that we can continue to work as we did, and then when you have been able to completely finish the transfer to Akonadi, bring back the new version?
(In reply to comment #10) > Could we please have the old addressbook back so that we can continue to work > as we did, and then when you have been able to completely finish the transfer > to Akonadi, bring back the new version? Then install SC 4.3 or bug your distributor to use KAddressbook 4.3 instead of 4.4.
(In reply to comment #11) > (In reply to comment #10) > > > Could we please have the old addressbook back so that we can continue to work > > as we did, and then when you have been able to completely finish the transfer > > to Akonadi, bring back the new version? > > Then install SC 4.3 Downgrading isn't all that easy in most cases... > or bug your distributor to use KAddressbook 4.3 instead of > 4.4. Tried that, they said there were too many changes to make this a viable option...
I shouldn't have posted emotions. I should have just explained the problem as I saw it. For that, I apologize. Oceanwatcher did a fantastic job of doing what I should have. Your decision to release an incomplete change in direction for the product has caused us to lose data. That is a BAD decision any way you want to look at it. Volunteer, professional, doesn't matter. You made an intentional decision that caused users to lose data. That is BAD. And come off your high horse about being a volunteer. Do you think any of us don't volunteer for anything in our lives? You do it because YOU enjoy it. You do it because YOU want to do it. And if you haven't already been financially rewarded or received a job because of what you've done, then be patient, it will come. But by volunteering, you assume the responsibilities associated with it. And one of those responsibilities surely has to be to never intentionally throw your users data away. I do appreciate your time and efforts on this but that doesn't change the fact that this was a really BAD decision. I upgraded because I wanted a bug fix that was made in KMail. I didn't want to touch any other part of KDE. But guess what, that isn't an option. I never expected to lose data because I upgraded. But I have learned my lesson. On Thursday 04 March 2010 11:02:47 am Tobias Koenig wrote: > https://bugs.kde.org/show_bug.cgi?id=222678 > > > > > > --- Comment #9 from Tobias Koenig <tokoe kde org> 2010-03-04 16:59:25 --- > (In reply to comment #7) > > > Categories have been DROPPED, and NOTHING has replaced them, and someone > > thought it would be OK to RELEASE!?!?!?!? Whoever is responsible should > > be smacked and never allowed to touch the source code again. This is an > > amazingly bad decision. > > Ok, as I'm the only developer of KAddressBook and responsible for the > release that means I'll shall stop working on KAddressBook and do > something else? Ok, if that's what you want?... I think you should think > twice before making such a stupid and inappropriate comment! > Maybe you haven't realized yet, but we do this development in our spare > time and we have a life next to it, studies, family etc. So instead of > insulting us you should be thankful that we provide software for free! > > /me is seriously pissed off
(In reply to comment #13) > I never expected to lose data because I upgraded. You didn't. It's just been hidden. Also, could you *please* refrain from fully quoting a comment when top-posting?
(In reply to comment #1) > Hej Dotan, > > the fields will be added in later versions of KAddressBook again. > As already stated in my blog entries, KAddressBook in 4.4 won't be > feature complete, the main target was to get a working version based > on Akonadi. Hi Thomas, It looks like what happened with the release of the new KAddressBook reflects in scale what happened with the release of KDE 4.0. On one hand KDE developers released KDE 4.0 before it had reached feature parity with KDE 3.5. This is because KDE developers intended KDE 4.0 as a technological preview aimed only at developers, testers and early adopters. On the other hand several KDE users expected KDE 4.0 to be released only after it had reached feature parity with KDE 3.5. This is (probably) because ".0" means final and feature complete in many free software projects around. While KDE 4.0 was a major upgrade, however, KDE 4.4 is a minor one. I would claim that it is reasonable then for KDE users to expect KDE 4.4 to maintain feature parity with KDE 4.3. I appreciate the efforts you and other KDE developers have spent in developing the brand new KAddressBook from scratch, but was it really necessary to release it as part of KDE 4.4? Was not it better to wait until KDE 4.5? I have always used categories intensively, and now the missing support for categories is obliging me to edit vCard files manually every time I add a new contact to the address book. This is so annoying. Unfortunately, I do not have time nor skills to contribute code, but I could make a donation to get this bug fixed as soon as possible. The donation would be done according to the proposal of "payment/donation to get bugs fixed" I made last year on the brainstorm forum of KDE: http://forum.kde.org/brainstorm.php#idea46860 Is this proposal interesting for you? Best regards.
Tobias, I am really sorry about the abuse you have been receiving over this. Your work is highly appreciated, however, it is more often those with a grudge or a problem who come to BKO, not those with a thank you. The attitudes shown here do not represent the Kaddressbook user community as a whole, who appreciate your hard work.
SVN commit 1101153 by tokoe: Bring back a new version of custom fields for contacts BUG: 222678 M +6 -0 CMakeLists.txt M +16 -0 contactmetadata.cpp M +24 -0 contactmetadata_p.h M +35 -4 contactviewer.cpp A customfieldmanager.cpp [License: LGPL (v2+)] A customfieldmanager_p.h [License: LGPL (v2+)] A customfields.cpp [License: LGPL (v2+)] A customfields_p.h [License: LGPL (v2+)] M +28 -0 editor/contacteditorwidget.cpp A editor/customfieldeditordialog.cpp [License: LGPL (v2+)] A editor/customfieldeditordialog.h [License: LGPL (v2+)] A editor/customfieldsdelegate.cpp [License: LGPL (v2+)] A editor/customfieldsdelegate.h [License: LGPL (v2+)] A editor/customfieldseditwidget.cpp [License: LGPL (v2+)] A editor/customfieldseditwidget.h [License: LGPL (v2+)] A editor/customfieldsmodel.cpp [License: LGPL (v2+)] A editor/customfieldsmodel.h [License: LGPL (v2+)] WebSVN link: http://websvn.kde.org/?view=rev&revision=1101153
Tobias, could you point out any differences to the KDE <= 4.4 implementation of custom fields?
Great work on getting custom fields back in, by the way. Dotan, could you split out the other parts of this bug report as separate reports? Multiple IM fields is already done, but I don't know about Categories or separate name component fields.
(In reply to comment #18) > Tobias, could you point out any differences to the KDE <= 4.4 implementation of > custom fields? We have 3 types of custom fields now: local, global and external. The local ones are defined by the user inside KAddressBook and they exists only for one specific contact. Their description is stored as custom attribute in the Akonadi item. This has the advantage that when you remove an item, its custom fields description get purged as well automatically. In <= 4.4 the custom fields descriptions has been stored in a separated config file for each contact, which lead to stale entries over time. The global custom fields exists for all available contacts and their descriptions are furthermore stored in a config file (namely $HOME/.kde/share/config/akonadi_contactrc). The external custom fields are those which come with imported contacts (e.g. a custom X- entry from a vCard exported by Evolution). These fields are read-only but are listed inside the custom field editor for informational purpose.
(In reply to comment #19) > Multiple IM fields is already done, but I don't know about Categories > or separate name component fields. Categories and separated name component fields have been implemented in SVN trunk already, therefor I waited for the last part (the custom fields) until I closed the bug... no further split needed here
What about multiple IM addresses?
Hi, I appreciate the introduction of Akonadi into KDE, althogh I do not yet know really, in which way it will change my work with the computer in the future. But I must say that I was also disappointed that features like categories were skipped in KAdressbook SC 4.4. Also, there still seem to be some rough edges in the program as it is often in the beginning. Here comes my suggestion: It would be nice if you guys would consider to provide two versions of the the programs which will be migrated to Akonadi in the future (like kmail). One stable version and one "experimental". Then, discussions like the one above would be unnescessary. I am not sure how much work that would be. But such PIM applications are very central to most users and I think KDE is aleady in such a good shape, so that people rely on the functionality of these programs.
I filed the multiple IM Address support bug here: https://bugs.kde.org/show_bug.cgi?id=230945
I appreciate all of the hard work put in by the KDE team. However, I have to agree with previous posters who pointed out that major functionality should not be removed in a regular (non-development) release. There are many customers using KDE in a business environment who expect feature stability. They also expect to perform regular updates to obtain bug fixes. I was using KDE 4.3 on Fedora 11 when the latest KDE 4.4 distribution came through a regular yum update. To my surprise, network address books no longer work reliably and the KMail auto-complete is broken. I'm unable to easily roll back to KDE 4.3, since the updates repository has already deleted those packages. It puts users in a very difficult situation when an upgrade is one-way, but features that were heavily used are removed without warning. Is there any way we can bring back the old address book as a parallel line until the new one is fully implemented? My time is limited, but I might be able to provide some help with this if I can get some guidance.
> Is there any way we can bring back the old address book as a parallel > line until the new one is fully implemented? That is up to your distro to implement. If you use Kubuntu or Ubuntu, then here is the feature request: https://bugs.launchpad.net/ubuntu/+source/kdepim/+bug/507990 Please discuss all "bring it back" ideas there. Thanks.
I am a user of Fedora, but I did take a look at the Kubuntu thread. It is impractical for a distribution to resolve this issue. The correct approach would be to restore the 4.3 addressbook until the 4.4 version is feature complete, perhaps releasing the updated version in 4.5. I will open a new KDE bug to discuss this topic.
Please reference bug 233078 for discussion on why this should be considered a regression and not a new feature request.