Hi Stephan,

Thanks for your work on this. I am actually at a calendaring conference at the moment, but I will look at this later in the week and do some Evolution testing myself.



On 01/28/2015 12:21 PM, Stephan wrote:
Hi,

I am aiming to run cyrus with caldav and carddav support. On the client side I am using evolution.

First step was compiling cyrus-imapd-2.4.14-caldav-beta10. After some configuration issues I managed to connect to my test calendar via browser/url and evolution. But I failed in doing some calendar entry because evolution tells me calendar is readonly.

I like your approach, so I tried to figure out whats going on. After verification of access rights with cryadm/lam I started with some wireshark-analysis. Which clarified for me that evolution obtains calendar access rights by doing an OPTION request.

This page showed me how it should look like :
http://lists.andrew.cmu.edu/pipermail/info-cyrus/2014-June/037418.html

I recognized that PUT (ALLOW_WRITE in cyrus code) is missing in my optionslist. While reviewing the code I found that

http_caldav.c/caldav_parse_path(...)

helps to determine values returned by the OPTION request. Path is splitted into
* collection
* resource

Where resource pointer is responsible for setting the ALLOW_WRITE option :

caldav_parse_path(...)
...
  done:
    /* Set proper Allow bits and flags based on path components */
    if (tgt->collection) {
...
    if (tgt->resource) {
        if (!tgt->flags) tgt->allow |= ALLOW_WRITE;
        tgt->allow |= ALLOW_DELETE;
        tgt->allow &= ~ALLOW_WRITECOL;
    }
...

When evolutions wants to determine calendar access rights it requests an collection but no resource. Because it wants to know about calendars access at all not some specific resource. But collection case doesn't set the ALLOW_WRITE flag. I guess that makes evolution mark calendar as readonly and prevents users from writing it.

I worked arround quickly by :

caldav_parse_path(...)
...
    tgt->collection = p;
    tgt->collen = len;

    p += len;
    if (!*p || !*++p) {
    /* Make sure collection is terminated with '/' */
    if (p[-1] != '/') *p++ = '/';
    if (!tgt->flags) tgt->allow |= ALLOW_WRITE;
...
    }

But evaluation of this is difficult to me. I am new to imap and your source. So I don't know if I missconfigured the build or misinterpret something. What do you say ?

Thank you in advance.

Stephan




--
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

Reply via email to