In KDE 4.12.80 the "categories" should probably use the new baloo based tags. Because after a migration it does not show any categories if editing a user, searching for a categorie that you have previously set, e.g. "family", does find them, though. Reproducible: Always Steps to Reproduce: 1. Update to 4.12.80 2. Migrate to baloo 3. Edit an existing contact 4. Open categories Actual Results: None are shown Expected Results: Correct categories are shown
Confirmed with current trunk. The problem seems to be that originally - before the switch from Nepomuk to Baloo - the contact's categories were stored in their text form. For example, this is an old contact (personal information removed) which has not been modified since the switch: $ akonadiclient show 499004 BEGIN:VCARD CATEGORIES:Friends UID:0KqAvlaaZq VERSION:3.0 END:VCARD $ However, this is a new contact which has been added since the switch: $ akonadiclient show 505367 BEGIN:VCARD CATEGORIES:akonadi:?tag=6 UID:1af9e6d2-f1ec-46fc-bcdc-26831c28b332 VERSION:3.0 END:VCARD $ I've checked this by instrumenting Akonadi::ContactsFilterProxyModel::contactMatchesFilter(). For an old contact, the contact.categories() at about line 225 returns the textual form of the categories; for a new one, the Akonadi URL is returned. This explains why searching for a previously categorised contact does find it.
Is it the intended functionality to eventually store the categories as references to akonadi/baloo tags in the vcf files (that will be decoded appropriately when displayed) , or is it a bug? I remember that earlier versions using nepomuk had a similar approach at one point (which was later fixed), storing resource id's instead of the category actual text in the vcf files, both those stored under ~/.local/share/contacts/ but also the exported ones. In case that this is by design and not a bug, I would strongly suggest that at least for the function of exporting to vcf files for backup/syncing/communicating reasons, the categories are saved as the actual text, since they are only usable this way on different systems.
See also bug 332358, bug 333899 and bug 333900
Still the same here. As much as I understand this is caused by the way the categories are stored after the migration to Baloo. As mentioned by Ioannis Ramfos this causes more problems e.g. when exporting contacts or synchronizing with an external server. See this bug https://bugs.kde.org/show_bug.cgi?id=332358. My workaround until now: I do not make any changes to contacts in Kaddressbook but only through the ownCloud frontend. That is not very convenient. I would propose to store the categories as they were stored in plain text. Moreover I would wish for a way to way to import my old categories. The Nepomuk-Baloo migrator did not take care of that. But they still are stored on the ownCloud server. I'm running KDE 4.14.5 and Akondi 1.13.0 on an up-to-date Chakra Linux.
One last remark. My old categories are still searchable in Kaddressbook. I even can search for new categories added through the ownCloud frontend. And when I export a contact the vcard file holds all categories - old ones and the new one from ownCloud - in plain text. But none of them appears in Kaddressbook.
For me, too, Akonadi is unusable for reliable PIM handling because of errors like this. Basically I resorted to using ownCloud web interface and Android clients to manage my PIM data, because Akonadi cannot be trusted. As I said in one of the other bugs, I'm really wondering if there is still any Akonadi development and bugfixing going on, or if it will go the way of other "pillars" of KDE4 sooner or later (anybody remembering the indispensable social desktop, Nepomuk, Strigi, stuff like that...).
I just gave KDE PIM suite 4.14.10 under openSUSE 13.2 another try. Had used the PIM suite in KDE3 for a long time but in the man time changed over to some other tools since I found that PIM suite 4 was pretty instable and unreliable. What I've seen now with 4.14.10 looks pretty well, but ... I'm also using Owncloud as server, and have lots of contacts with categories assigned. As mentioned earlier this works well with the Owncloud web interface, Thunderbird with SOGO connector, and my Android smartphone with CalDAV sync. Unfortunately, if I add my Ownlcoud address books to kaddressbook then the categories are not imported and listed. In kaddressbook there is only one predefined category, "birthday", and I can only try to add additional categories manually. However, even much worse, when I edit an existing contact and e.g. modify the email address only then all categories are removed when the modified contact is saved in Owncloud, so my contact list is really messed up. This is really a showstopper for me. Is it so hard to get this working properly and leave existing fields in the carddav record at least untouched when the record is written back?
(In reply to Martin Burnicki from comment #7) +1