No support for read-only access in CalDAV-Sync (android)
Open, 60Public


When using the iRony, apparently the android client CalDAV-sync, does not receive information about some available shared calendars being read-only. Therefore the calendaring client can select a read-only calendar and create events, which will not be synced but stay in the local calendar, this is unclear to the client and might even lead to data loss. Some other services (e.g. SOGo) apparently supply some information about the read/write access to the CalDAV client, and avoid this issue.


Ticket Type
bff created this task.Jan 1 2017, 11:57 PM

This is RFC 3744 which has to be implemented. We have a ticket for this (T756), but that one is about WebDAV. Let's keep a separate ticket for CalDAV.

machniak removed a project: Bug Reports.

Because there's more to do for full sharing support. See However, ACLs are already exposed but apparently not respected by all clients.

pasik added a subscriber: pasik.Nov 25 2017, 2:33 PM
dfaure added a subscriber: dfaure.EditedApr 28 2018, 11:40 AM

I cannot confirm that ACLs are already exposed. Looking at the DAV response I get on the client side, for a readonly folder, shows:

<d:prop xmlns:d="DAV:">

 <d:displayname xmlns:d="DAV:">(helena) Vacations</d:displayname>

 <d:resourcetype xmlns:d="DAV:">

 <d:collection xmlns:d="DAV:"/>

 <cal:calendar xmlns:cal="urn:ietf:params:xml:ns:caldav"/>


 <x5:calendar-color xmlns:x5="">#FB0055FF</x5:calendar-color>

 <cal:supported-calendar-component-set xmlns:cal="urn:ietf:params:xml:ns:caldav">

 <cal:comp xmlns:cal="urn:ietf:params:xml:ns:caldav" name="VEVENT"/>


 <d:current-user-privilege-set xmlns:d="DAV:">

 <d:privilege xmlns:d="DAV:">

 <d:write xmlns:d="DAV:"/>


 <d:privilege xmlns:d="DAV:">

 <d:write-acl xmlns:d="DAV:"/>


 <d:privilege xmlns:d="DAV:">

 <d:write-properties xmlns:d="DAV:"/>


 <d:privilege xmlns:d="DAV:">

 <d:write-content xmlns:d="DAV:"/>



which, if I understand this correctly, says I have write permissions to that folder (which I don't). Is that getACL not called, or misbehaving, possibly?