| Summary: | Kontact/kmail change resource type on KOLAB resource | ||
|---|---|---|---|
| Product: | [Applications] kontact | Reporter: | Georg Greve <greve> |
| Component: | general | Assignee: | kdepim bugs <kdepim-bugs> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | djacks555, kdenis, vanmeeuwen, winter |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Debian testing | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
Just discovered this is also likely the cause of https://bugs.kde.org/show_bug.cgi?id=161388 *** Bug 161388 has been marked as a duplicate of this bug. *** Georg, Can you give me a step-by-step test I can use to try and debug this? I created a calendar type folder under Kolab Server/inbox. Then quit and restarted Kontact and that folder is still a calendar type. So I'm guessing this isn't a good enough test. Hi Allen, Apologies for the delay. After it happened about every second time before filing the report, I haven't been able to reproduce the bug, primarily as I have been playing around with my system to see whether I could track it down - and it seems like somehow kded has given up its ghosts while doing so (see http://lists.kde.org/?l=kde&m=125249396616682&w=2). The working hypothesis from someone else with who I discussed the issue was that it was caused by caching / crash interaction, which is possible because I am among those affected by https://bugs.kde.org/show_bug.cgi?id=191589 and Kontact crashes regularly on network hick-ups. So we thought that when kontact crashes things might be left in an unclean state, and upon restart it believes its own cache (or tries to put it back into "sane" state) instead of asking the server for the correct values and taking those. But I could not confirm or disprove this theory so far. Will get back to it once I've resolved those kded issues. Alright, my KDE is back among the living, apparently KDE3 and KDE4 kded should not be run in parallel, seems like a Debian dependency issue: http://lists.kde.org/?l=kde&m=125317961600882&w=2 So back to this issue. The way to reproduce this problem here is with the following setup: a) create a group user account on the KOLAB server b) give your own user full permissions (including admin) on that user's account c) create sub-calendars in the calendar folder from your kontact d) fill in some data, make sure it's all synchronised to invoke the bug, I crash kontact, for me https://bugs.kde.org/show_bug.cgi?id=191589 works reliably once or twice a day or so. Select "close" on the crash dialog and kill all the lingering cache processes that the crash left to get a clean startup of Kontact. Start Kontact again. Now the Groupware folders of the group user are of folder-type mail, but *NOT* the Calendar subfolders for some reason. This works every second or third time from what I can see. Just had another incidence of the exact behavior described in my last message. The killing all residual caching processes of kontact/kmail after a crash or just to get them to integrate properly (*) is probably the critical step in reproducing this bug. Hope this helps to narrow it down. (*) When starting KDE, both kmail and kontact appear to be starting up, but when selecting "mail" in kontact, I get a separate window for kmail. The only way to resolve this is to kill both applications, kill all residual caching & remaining processes on the commandline, and then restart kontact. While I've seen the original one issue occur (change of /vendor/kolab/folder-type annotation on groupware folders) long time ago, I've not noticed any such happening lately (>= 4.5 or 4.6 perhaps?). If you could please confirm/deny this has happened to you lately, Georg, we'd all appreciate. Until such time, as I seem to be unable to trigger and reproduce this issue, I'm setting the status to NEEDSINFO |
Version: Kontact version 4.3.1, KMail version 1.12.1 (using KDE 4.3.0) OS: Linux Installed from: Debian testing/unstable Packages Kontact (or Kmail, which may be the actual culprit, as it is the application handing the IMAP folders, AFAIK) is changing the resource type on additional resources (an additional address book, an additional calendar) of the KOLAB groupware folders (from calendar or address book to mail). This is a violation of the KOLAB specification, and folders are consequently displayed as mail folders in Kmail, instead of as address books or calendars. The folder type can be restored by hand with the mboxcfg <mailbox> /vendor/kolab/folder-type {event,contact} command in cyradm on the server, after which Kontact will again display the resource correctly until it changes its type back to "mail" again. Note that the bug does not seem to affect the "standard" resources ("Contacts" "Calendar") but only those that are additionally created. So there may already be provisions that prevent changing those folders, but the logic may be hard-coded on the Contacts/Calendar folders, instead of KOLAB groupware folders in general. Also not entirely sure whether this is caused by Kontact or Kmail, so this bug may need bouncing over to Kmail. Either way: Kontact/Kmail must never change the folder type on KOLAB groupware resources.