Page MenuHomePhorge

No support for read-only access in CalDAV-Sync (android)
Closed, WontfixPublic

Description

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.

Details

Ticket Type
Task

Event Timeline

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.

Because there's more to do for full sharing support. See http://sabre.io/dav/caldav-sharing/. However, ACLs are already exposed but apparently not respected by all clients.

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"/>

 </d:resourcetype>

 <x5:calendar-color xmlns:x5="http://apple.com/ns/ical/">#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"/>

 </cal:supported-calendar-component-set>

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

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

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

 </d:privilege>

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

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

 </d:privilege>

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

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

 </d:privilege>

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

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

 </d:privilege>

...

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?

Ping? Any feedback on the wrong write privilege returned for (shared) readonly folders?

vanmeeuwen lowered the priority of this task from 60 to Normal.Mar 28 2019, 8:12 AM

Any chance this will get fixed/implemented soon?
Thunderbird + TbSync + DAV-4-TbSync suffers from this, too.

The ACLs for shared readonly adressbooks are exposed correctly but not for readonly calendars.

Could someone please look into this as this leads to problems with invitations with other clients.

I'm unable to reproduce. current-user-privilege-set is correct for other user's calendar with lrs permissions. Could you enable debug and provide full request and response for the PROPFIND on a readonly calendar?

Hallo machniak,

I've contacted John Bieling (developer of TbSync and DAV-4-TbSync) and he instructed me to send him a debug Log through TbSync.
This showed him full access rights for the shared "readonly" calendar and said that he can't do nothing about this.
Sadly I do not have this debug log anymore.

kolab-lam shows the correct rights (lrs) but when using TbSync+DAV-4-TbSync Addons in Thunderbird it does not detect the calendar as "readonly".
Clould it be that iRony shows the owners ACLs instead of the "shared" ones?

Could you instruct me how I can get the information you need?

iRony has two debug options that should give some logs.

// enable debug console showing the internal function calls triggered
// by http requests. This will write log to /var/log/iRony/console
$config['kolabdav_console'] = true;

// enable logging of full HTTP payload
// (bitmask of these values: 2 = HTTP Requests, 4 = HTTP Responses)
$config['kolabdav_http_log'] = 6;

You may also enable imap_debug and sql_debug (from Roundcube Framework).

Ok, I have the two log files console.log and httpraw.log.
Where can I send them? They contain sensitive data?
When I send them they will be send from my business address and not from this account.

machniak claimed this task.