Bug 222678 - Missing fields in new Kaddressbook for KDE SC 4.4
Summary: Missing fields in new Kaddressbook for KDE SC 4.4
Status: RESOLVED FIXED
Alias: None
Product: kaddressbook
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Unlisted Binaries Unspecified
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-01-14 11:33 UTC by Dotan Cohen
Modified: 2010-07-25 14:05 UTC (History)
12 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dotan Cohen 2010-01-14 11:33:47 UTC
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.
Comment 1 Tobias Koenig 2010-01-14 12:57:09 UTC
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
Comment 2 Jason G. Pallack 2010-01-24 19:14:11 UTC
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.
Comment 3 Oceanwatcher 2010-01-31 19:08:05 UTC
Hmmm.... Isn't Kubuntu 9.10 an LTE and going to be based on 4.4?
Comment 4 Dotan Cohen 2010-01-31 20:20:26 UTC
> 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
Comment 5 Colin Woods 2010-02-12 22:26:54 UTC
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.
Comment 6 Colin Woods 2010-02-13 16:33:13 UTC
Actually,

Answered question myself.  A cat of the addressbook vcf files showed the fields to still be present.

Colin.
Comment 7 mfb_kdebugs9 2010-03-02 06:20:58 UTC
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.
Comment 8 Dj YB 2010-03-02 08:40:23 UTC
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.
Comment 9 Tobias Koenig 2010-03-04 16:59:25 UTC
(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
Comment 10 Oceanwatcher 2010-03-04 18:24:32 UTC
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?
Comment 11 markuss 2010-03-04 18:42:01 UTC
(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.
Comment 12 ancow 2010-03-04 18:53:16 UTC
(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...
Comment 13 mfb_kdebugs9 2010-03-04 19:56:46 UTC
  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
Comment 14 ancow 2010-03-04 20:20:34 UTC
(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?
Comment 15 Alessandro Rossini 2010-03-06 15:26:46 UTC
(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.
Comment 16 Dotan Cohen 2010-03-06 17:35:30 UTC
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.
Comment 17 Tobias Koenig 2010-03-09 14:30:27 UTC
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
Comment 18 Will Stephenson 2010-03-09 22:56:42 UTC
Tobias, could you point out any differences to the KDE <= 4.4 implementation of custom fields?
Comment 19 Will Stephenson 2010-03-09 23:01:12 UTC
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.
Comment 20 Tobias Koenig 2010-03-10 10:26:53 UTC
(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.
Comment 21 Tobias Koenig 2010-03-10 10:28:38 UTC
(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
Comment 22 Dotan Cohen 2010-03-10 16:48:35 UTC
What about multiple IM addresses?
Comment 23 Stefan Vater 2010-03-13 15:24:14 UTC
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.
Comment 24 Dotan Cohen 2010-03-16 10:39:22 UTC
I filed the multiple IM Address support bug here:
https://bugs.kde.org/show_bug.cgi?id=230945
Comment 25 Kumaran Santhanam 2010-04-02 02:29:05 UTC
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.
Comment 26 Dotan Cohen 2010-04-02 09:37:13 UTC
> 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.
Comment 27 Kumaran Santhanam 2010-04-02 16:01:08 UTC
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.
Comment 28 Kumaran Santhanam 2010-04-02 19:19:17 UTC
Please reference bug 233078 for discussion on why this should be considered a
regression and not a new feature request.