Bug 338648

Summary: New kdepim-runtime 4.14 resource kolab doesn't show mail or contact/task/calender/... informatio
Product: [Frameworks and Libraries] Akonadi Reporter: Franz Schrober <franzschrober>
Component: Kolab ResourceAssignee: kdepim bugs <kdepim-bugs>
Status: RESOLVED UNMAINTAINED    
Severity: normal CC: franzschrober, kdepim-bugs, mollekopf, montel
Priority: NOR    
Version: GIT (master)   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed In:

Description Franz Schrober 2014-08-29 09:34:41 UTC
I've noticed that kdepim-runtime 4.14 now provides a new kolab resource which explicitly states that the old kolab-proxy is obsolete and should not be used. So Ive started to migrate my setup to use this new resource to replace my imap and kolab-proxy resource. The first step was to just add the kolab resource in akonadi and change the settings to be the same as my imap setup (beside the name of course).

After ages of downloading my mails, nothing was visible in kmail2 or in korganizer/kaddressbook/... The akonadiconsole showed the new resource with all my mail folders and the mails (and their content). So it looks like everything was downloaded. Also restarting the complete system didn't solve anything.

I am not sure if it helps but I've compared the folder properties of INBOX (with the old imap resource) and my INBOX/Calender (with kolab-proxy resource) folder in akonadiconsole:

* INBOX
** imap:
*** ENTITYDISPLAY: ("Inbox" "mail-folder-inbox" "" ())
*** uidnext: 13032
*** collectionflags: \Answered \Flagged \Deleted \Seen \Draft Old $FORWARDED $SENT $REPLIED $SIGNED $ATTACHMENT $ENCRYPTED $TODO $WATCHED $IGNORED $QUEUED \*
*** timestamp: 1409303565
*** uidvalidity: 1294437727
*** highestmodseq: 28805
*** Content-Types:
**** message/rfc822
**** inode/directory
** kolab
*** ENTITYDISPLAY: ("Inbox" "mail-folder-inbox" "" ())
*** accessrights: a
*** timestamp: 1409303529
*** Content-Types:
**** inode/directory
**** application/x-kolab-objects
* Calender
** kolab-proxy
*** ENTITYDISPLAY: ("" "view-calendar" "" ())
*** uidnext: 230
*** AccessrRights: a
*** collectionflags: \Answered \Flagged \Deleted \Seen \Draft Old \*
*** timestamp: 1409303564
*** uidvalidity: 1294437785
*** collectionannotations: /vendor/kolab/folder-type event.default
*** highestmodseq: 380
*** Content-Types:
**** inode/directory
**** application/x-vnd.akonadi.calendar.event
** kolab
*** uidnext: 230
*** AccessRights: a
*** collectionflags: \Answered \Flagged \Deleted \Seen \Draft Old \*
*** timestamp: 1409303529
*** uidvalidity: 1294437785
*** highestmodseq: 380
*** Content Types:
**** inode/directory
**** application/x-kolab-objects
Comment 1 Franz Schrober 2014-11-18 12:55:58 UTC
No reaction from the author. So just adding him
Comment 2 Franz Schrober 2014-11-18 14:22:09 UTC
I found at least a workaround.

1. Check that you really have metadata enabled on your imap server
2. delete imap and kolab resources in akonadi which are somehow related to this account
3. connect manually to your imap server and reset the metadata for all relevant folders (may be different paths on your account)
$ openssl s_client -starttls imap -connect example.com:143
a1 LOGIN secretusername secretpassword
a2 SETMETADATA "INBOX/Contacts" ("/shared/vendor/kolab/folder-type" "contact.default")
a3 SETMETADATA "INBOX/Journal" ("/shared/vendor/kolab/folder-type" "journal.default")
a4 SETMETADATA "INBOX/Tasks" ("/shared/vendor/kolab/folder-type" "task.default")
a5 SETMETADATA "INBOX/Calendar" ("/shared/vendor/kolab/folder-type" "event.default")
a6 SETMETADATA "INBOX/Notes" ("/shared/vendor/kolab/folder-type" "note.default")
a7 SETMETADATA "INBOX/FreeBusy" ("/shared/vendor/kolab/folder-type" "freebusy.default")
a8 SETMETADATA "INBOX/Configuration" ("/shared/vendor/kolab/folder-type" "configuration.default")
a9 SETMETADATA "INBOX/File" ("/shared/vendor/kolab/folder-type" "file.default")
a10 SETMETADATA "INBOX" ("/shared/vendor/kolab/folder-type" "mail.inbox")
a11 SETMETADATA "Drafts" ("/shared/vendor/kolab/folder-type" "mail.drafts")
a12 SETMETADATA "Sent" ("/shared/vendor/kolab/folder-type" "mail.sentitems")
a13 SETMETADATA "Trash" ("/shared/vendor/kolab/folder-type" "mail.wastebasket")
a14 SETMETADATA "Junk" ("/shared/vendor/kolab/folder-type" "mail.junkemail")
4. restart akonadi
5. add a kolab (not imap, not kolab-proxy) resource to akonadi
6. wait ages until all your mails are synced

These steps weren't necessary with the old kolab-proxy+imap. And I am not yet sure if all was downloaded because it still downloads. But at least some mails are now visible.
Comment 3 Denis Kurz 2017-06-23 20:05:01 UTC
This bug has never been confirmed for a KDE PIM version that is based on KDE Frameworks (5.x). Those versions differ significantly from the old 4.x series. Therefore, I plan to close it in around two or three months. In the meantime, it is set to WAITINGFORINFO to give reporters the oportunity to check if it is still valid. As soon as someone confirms it for a recent version (at least 5.1, ideally even more recent), I'll gladly reopen it.

Please understand that we lack the manpower to triage bugs reported for versions almost two years beyond their end of life.
Comment 4 Denis Kurz 2018-02-01 09:52:33 UTC
Just as announced in my last comment, I close this bug. If you encounter it again in a recent version (at least 5.1 aka 15.12; preferably much more recent), please open a new one unless it already exists. Thank you for all your input.