Bug 303861

I have exactly the same Problem (both on Ubuntu 12.04 and on Gentoo). It might be connected to (or the same as) https://bugs.kde.org/show_bug.cgi?id=273949
If I remember correctly it used to work with some older ubuntu version (11.10 or 11.04).

I can confirm this bug using a dav-groupware-ressource: 
An empty attribute "AccessRights" is placed for this ressource every time akonadiserver starts. Deleting "AccessRights" using akonadiconsole makes it writeable but after restarting akonadiserver this empty attribute appears again making it read only. 
Also placing the rights "wcdW" (copied from the personal calendar - also making it writeable) are removed after a restart. Again an empty "AccessRights". 
I'm using davmail running locally to connect to my companys' exchange (2010) server calendar. It's working as long as you don't restart akonadiserver.

 KDE 4.9.00 on kubuntu 12.04 Please fix this!

I can also confirm this bug. Also, deleting empty attribute "AccessRights" fixes the issue temporarily.

Ah yes, Kubuntu 12.04 here.

(In reply to comment #4)
> Ah yes, Kubuntu 12.04 here.

We need the KDE version, not the distribution one.

(In reply to comment #5)
> (In reply to comment #4)
> > Ah yes, Kubuntu 12.04 here.
> 
> We need the KDE version, not the distribution one.

KDE 4.8.x and KDE 4.9.x

KDE Platform Version 4.8.4 (4.8.4)

Just updated to Platform Version 4.8.5 (4.8.5) and the behaviour is still the same. 

BTW, I am syncronizing both my Google calendar and local caldav using the DAV groupware resource, and I have write access to my Google calendar, but not to my local caldav.

Just checked attributes on my Google calendar folder (that I have write access to) and it shows AccessRights with value 'a'.

Confirmed on 4.8.x, can somebody else than the original reporter confirm on 4.9 as well?

Confirmed on 4.9.1!!!

this will be really hard to fix and test if the problem is specific to Exchange's CalDAV.

is there some free site where I can test?  I use CalDAV with Google Calendar and can write there without any problems.

(In reply to comment #12)
> this will be really hard to fix and test if the problem is specific to
> Exchange's CalDAV.
> 
> is there some free site where I can test?  I use CalDAV with Google Calendar
> and can write there without any problems.

The problem can probably been found by Code Inspection. The same setup with Exchange CardDav works.
Another hint is to look into another minor issue: the name of the Calendar also can't be changed in the Calendar Folder Properties, might be the same reason.
I can contribute with some strace logs if that helps.

/me too

I have the same problem (KDE 4.9.0 on KUbuntu 12.04), and I can confirm that removing the AccessRights property is a temporary workaround.

As written in comments 64/65 of bug #273949, this is no duplicate, but a specific problem with this davmail setup.

Therefore, I believe a fix involving some special casing would be in order.

AFAICS, davmail is currently the only way for accessing Exchange servers (in corporate environments), so I would say fixing this should have a high priority.

I just realized that this is not as easy to fix as I originally believed: Of course it would be necessary to get the proper access rights through davmail, since one does not have write permissions on all calendars.  For instance, I have setup three calendars within the "DAV groupware resource", two of which are shared calendars managed by the office staff (i.e. they are effectively read-only for me).

I have this issue in KOrganizer 4.8.5 and DavMail 4.0.0-2016. This issues seems to be that when Akonadi (1.7.2) connects to the DavMail resources it creates the calendar directory with modification rights and it also creates a blank "AccessRights" attribute.

Did anybody here look at the relevant code yet?  (Harry?)
Looks to me as if https://projects.kde.org/projects/kde/kdepim-runtime/repository/revisions/master/show/resources/dav is relevant, but only davgroupwareresource.cpp seems to contain code managing access rights.

Hi,

Without access to an Exchange server this will be hard to debug unfortunately :/

If any of you can do a network capture of a full exchange between the resource and davmail, please send it to me. Try to anonymize it as much as you can, especially the HTTP headers that will contain the authentication data. I'm mostly interested in the XML exchanges, not that much in the events data, so you can scrap it altogether.

Cheers,
Grégory

My daily workaround is to bring up akonadiconsole and remove the blank AccessRights attribute from the Calendar folder under the DavMail agent.

(In reply to comment #18)
> Hi,
> 
> Without access to an Exchange server this will be hard to debug
> unfortunately :/
> 
> If any of you can do a network capture of a full exchange between the
> resource and davmail, please send it to me. Try to anonymize it as much as
> you can, especially the HTTP headers that will contain the authentication
> data. I'm mostly interested in the XML exchanges, not that much in the
> events data, so you can scrap it altogether.
> 
> Cheers,
> Grégory

(In reply to comment #19)
> My daily workaround is to bring up akonadiconsole and remove the blank
> AccessRights attribute from the Calendar folder under the DavMail agent.

Yup, I understand that. The resource is not able to understand the access rights DavMail sends back, so I'd like to see the raw XML exchange between the resource and DavMail. It'd help debug the issue.

Cheers,
Grégory

Grégory, I would be willing to supply that (best by email, I think), but can you advise on the proper way of capturing?  Shall I use dumpcap/wireshark?  Can you give a hint on filters etc. to set up to get a better overview / smaller capture?

(In reply to comment #21)
> Grégory, I would be willing to supply that (best by email, I think),

Excellent, thanks!

> but can
> you advise on the proper way of capturing?  Shall I use dumpcap/wireshark? 

If you have wireshark then it's the simplest way to go. It has some neat features that'll be helpful.

> Can you give a hint on filters etc. to set up to get a better overview /
> smaller capture?

Well, you should only capture communications on the port used by DavMail (1080 apparently, but adapt to your case as it can be customized). Then once wireshark is started, launch akonadiconsole and, in the first tab, right click on the agent. From the pop-up menu, in the 'Synchronize' entry select 'Synchonize Collection tree', and let the resource do its job.

Once it's done you can stop the capture and begin looking at the packets. The nice feature of Wireshark is that you can get the HTTP conversation decrypted quite easily: right click on a packet of the TCP stream and select 'Follow TCP stream'. Here you'll have to find the one with a XML response from DavMail. If it's not the first one you pick, just close the window that just opened, and clear the filter (it should read 'tcp stream eq X', where X is an integer).

I hope this is all clear, but feel free to ask if that's not the case.

Cheers,
Grégory

After chatting with Grégory by mail, I have opened a davmail bug, too:
https://sourceforge.net/tracker/?func=detail&aid=3579112&group_id=184600&atid=909904

Git commit 88f3599be25a694bb355710f1631f6e3f6da488a by Grégory Oestreicher.
Committed on 22/10/2012 at 18:34.
Pushed by goestreicher into branch 'KDE/4.9'.

Accomodate more than one privilege at once in <privileges/>

This is needed for at least DavMail, that returns more
than one privilege in the <privileges/> tag in response
to current-user-privilege-set requests. Not sure if
this is RFC3744 compliant, but it's a painless fix.

M  +30   -24   resources/dav/common/davcollectionsfetchjob.cpp

http://commits.kde.org/kdepim-runtime/88f3599be25a694bb355710f1631f6e3f6da488a

Thanks for fixing that - I will test 4.9.3 as soon as it is available.
Nevertheless, there was a different behavior between access rights of calendar and contact items. Contacts allway worked with davmail. For me it seems, that there might be an underlying bug in carddav ignoring the access rights at all. I can't test for that since I have write access allways on carddav items.
Grégory, can you please check for the same mechanism in caldav and carddav?

Thanks, Jens.

(In reply to comment #25)
> Thanks for fixing that - I will test 4.9.3 as soon as it is available.
> Nevertheless, there was a different behavior between access rights of
> calendar and contact items. Contacts allway worked with davmail.

As CalDav and CardDav share a lot of code, including the access rights management, my best guess would be that DavMail replies differently. The only way to be sure would be with a network capture.

> For me it
> seems, that there might be an underlying bug in carddav ignoring the access
> rights at all.

Full access can be granted if the CardDav answer does not contain any privileges specification or explicitly states that all privileges are granted. Without the XML of the exchange it's impossible to tell which is happening.

I'll insist heavily on that: a network capture speeds up the debugging drastically. It only took a couple of minutes to find the problem once Hans sent me one. If you need the process (with Wireshark) I have it at hand :)

Cheers,
Grégory

Can you send those wireshark instructions to me as well?

(In reply to comment #26)
> (In reply to comment #25)
> > Thanks for fixing that - I will test 4.9.3 as soon as it is available.
> > Nevertheless, there was a different behavior between access rights of
> > calendar and contact items. Contacts allway worked with davmail.
> 
> As CalDav and CardDav share a lot of code, including the access rights
> management, my best guess would be that DavMail replies differently. The
> only way to be sure would be with a network capture.
> 
> > For me it
> > seems, that there might be an underlying bug in carddav ignoring the access
> > rights at all.
> 
> Full access can be granted if the CardDav answer does not contain any
> privileges specification or explicitly states that all privileges are
> granted. Without the XML of the exchange it's impossible to tell which is
> happening.
> 
> I'll insist heavily on that: a network capture speeds up the debugging
> drastically. It only took a couple of minutes to find the problem once Hans
> sent me one. If you need the process (with Wireshark) I have it at hand :)
> 
> Cheers,
> Grégory

(In reply to comment #27)
> Can you send those wireshark instructions to me as well?
Have a look at comment #22 ...

Actually, I used

  sudo dumpcap -i lo -n -f "port 1080"

for capturing and then started wireshark as normal user with the resulting file as parameter.

(In reply to comment #27)
> Can you send those wireshark instructions to me as well?

As Hans pointed out I've put the instructions in comment #22. I thought that I gave them in a private mail.

Cheers,
Grégory

(In reply to comment #29)
> (In reply to comment #27)
> > Can you send those wireshark instructions to me as well?
> 
> As Hans pointed out I've put the instructions in comment #22. I thought that
> I gave them in a private mail.
> 
> Cheers,
> Grégory

I have the xml responses ready, but I don't know what I am exactly looking for and which part you need. There is no response like  "<D:privilege><D:read/><D:write/></D:privilege>".
On the other hand (not knowing the specifications) I am not sure if it would make sense for the adressbook. While it is possible to share calendars in Exchange and have different privileges for those, there is no adressbook sharing. At least as far as I know. So I assume one should have always write permissions to the adressbook?

And by the way, thanks for fixing/debugging this.

(In reply to comment #30)
> I have the xml responses ready, but I don't know what I am exactly looking
> for and which part you need.

One of the resource requests should contain <current-user-privilege-set/>. Look at the server response for a matching tag, and the ones enclosed in it.

> There is no response like 
> "<D:privilege><D:read/><D:write/></D:privilege>".

OK, so this may mean that no ACL is set on the addressbook. In that case the resource gives you all privileges.

> On the other hand (not knowing the specifications) I am not sure if it would
> make sense for the adressbook. While it is possible to share calendars in
> Exchange and have different privileges for those, there is no adressbook
> sharing. At least as far as I know. So I assume one should have always write
> permissions to the adressbook?

I'm not using Exchange so I can't be sure how it works, but with other groupware solutions you can have multiple address books such as a corporate one and a personal one. No one should be able to write to the corporate, so ACLs come in play here.

Cheers,
Grégory

(In reply to comment #31)
> I'm not using Exchange so I can't be sure how it works, but with other
> groupware solutions you can have multiple address books such as a corporate
> one and a personal one. No one should be able to write to the corporate, so
> ACLs come in play here.

I think the corporate adressbook with exchange+davmail is exposed via ldap, but I am not sure about that because I don't use it. So at least for me the carddav part seems to be unproblematic at the moment, because davmail does not send any ACL for the adressbook (I have checked again, there is no <current-user-privilege-set/> in the xml response for carddav). But I don't know if there are exchange+davmail setups out there where this is a problem...

I just installed KDE 4.9.3 - the bug is fixed.

Thanks.

I can confirm that bug is fixed indeed: Using Kontact 4.9.3 + Davmail, I can add calendar events to a MS Exchange server calendar.