Hello, all. We are trying to use Kontact (1.2.9) as a front end to our Zimbra (6.0.5) server. The clients are running Debian Lenny + backports.

We have tried to synchronize our contacts two different ways. In both cases, we configured the zimbra account as disconnected IMAP. We then set up a resource as a directory and pointed it to the appropriate dimap directory. We then learned that we could fix the IMAP resource by manually setting the TheIMAPResourceAccount= parameter. That worked beautifully and pulled down all the address books.

However, in all cases we had the same problem. Contacts flow perfectly from zimbra to Kontact but any changes or additions in Kontact fail to propagate to Zimbra. We get an APPEND FAILED error. How does one create writable access to contacts on a Zimbra server? Thanks - John

Have you checked this? http://www.zimbra.com/forums/users/9285 ... ntact.html

According to that page, KDE 4.5 will have improved support for Zimbra..

http://www.zimbra.com/forums/evolution- ... eeded.html might help also.

Yes, I have. In fact, I posted to it as KDE 4.5 is not an option for us.

I thought I would simply unsubscribe the calendar but, bizarrely, it does not show up as a subscribed folder. Any idea how I can unsubscribe it? Right now, I have to click through an error message about the Calendar file not existing every time I synchronize. As I mentioned in another thread, it looks like the IMAP request is malformed. Our users will certainly not stand for that kind of continuous interruption to their work. Thanks - John

The problem with the constant Calendar error message and possible malformed URI seems to be related to the IMAP Resource code. The Calendar folder does not appear on the initial IMAP synchronization. However, when I enable IMAP Groupware Resources and set the folder location, the Calendar IMAP folder appears and the persistent error message about not being able to find myserver.mycompany.com:993Calendar starts (I assume it should be myserver.mycompany.com:993/Calendar).

If I instead disable IMAP Groupware and access the contacts by creating Directory Resources pointing to the dimap folders, I do not get this problem.

However, I still have the original two problems.

1) Updates to contacts fails complete with a cannot APPEND error.
2) Updates to calendar (webdav) succeed but generate an error message saying it failed.

Any idea how to address these last two? Thanks - John

According to http://www.zimbra.com/forums/56343-post2.html Contacts are read-only if accessing them over IMAP. As a workaround, you may be able to use LDAP.

No idea why Calendar updates fail, however if the calendars are large that is the likely cause of the problem. using CalDav would likely support that.

If KDE 4 is being used, you may wish to check http://code.google.com/p/kcaldav/

Thanks. Despite an extensive search, I missed that one and have vote for the RFE. We'll have to dig further on the calendar issue. Alas, we are still on KDE 3.5.

One item I forgot to mention is that we also fail to get the free/busy information. Does anyone have any idea of how we configure that between Kontact and Zimbra? Thanks again - John

The Free/Busy issue you are experiencing appears to be due to http://bugzilla.zimbra.com/show_bug.cgi?id=28435

Unless you can find a way to generate that authentication key, this probably isn't possible...
( Although http://wiki.zimbra.com/wiki/ZCS_6.0:Zim ... t_FreeBusy provides some information which may help )

Not sure if this is the method you used to implement Calendar support, but this may help also: http://www.zimbra.com/forums/69852-post2.html

I almost have the free/busy times working. Thanks very much for the lead. The 7070 REST interface does not work but it gave me enough of the syntax to make headway.

If I specify a path including the user, e.g.,
https://zimbra.mycompany.com/home/someu ... m/?fmt=ifb
it works perfectly.

However, how does Kontact fill in the user information from variables so we can set it in settings and not for each user? In the Calendar settings for Retrieve Free/Busy I tried:
https://zimbra.mycompany.com/home/%u@%d/?fmt=ifb
but it does not work. That was a guess based upon Evolution documentation. I've not yet found anything in the KDE docs but am still looking. Thanks - John

Have you checked the option to use the full username@domain format on the retrieve dialog?

The KDE 3 version does look geared towards Kolab though... which will work still if Zimbra accepts https://zimbra.mycompany.com/home/%u@%d.ifb

Regarding the time zone issue, your KDE timezone and the time zone in Kontact are set correctly?

Thank you for your help. This seems frustratingly close. The option to use the full username@domain format is checked. The option to do automatic retrieval was not checked as I assumed that meant to retrieve regularly in the background and not on demand. I assumed that must have been my error and so checked it and restarted Kontact. Alas, no success. I do now see it trying; there is a brief flicker in the attendee list but no schedule retrieved. It simply displays the black mesh fill even where I know there are existing appointments.

Zimbra does not appear to take the https://zimbra.mycompany.com/home/%u@%d.ifb syntax. If I replace this with the actual name in the dialog which appears when I double click an attendee in the meeting creation dialog, I get nothing. It seems to clearly want https://zimbra.mycompany.com/home/%u@%d/?format=ifb. If I replace %u@%d with the real user name and domain in the aforementioned dialog, it works perfectly.

In case I've braincramped on a typo, here is the actual string used in my Kontact set up but with a changed server and domain:

https://zimbra.mycompany.com/home/%u@%d/?fmt=ifb

If nothing is obvious, I may need to enable clear text and do a trace to see what exactly Kontact is putting on the wire. For kicks, I tried unchecking use full name and domain and that failed, too.

Regarding time zone, KDE and KOrganizer are set to New York/America as they should be. I do not see a separate setting for Kontact. My task bar clock displays properly.

What next? Thanks again - John