CALDAV reports wrong ACLs

[Skale, Franz]

Hi,
i think there's an open task on that issue.
Take a look at the git repo.
You should submit your findings there.
Link: https://git.kolab.org/T2157

Rgds.
Franz



Am 2018-04-27 09:55, schrieb David Faure:
> Hello,
> 
> I've been debugging an issue in the KDE Caldav resource, and it turns
> out to be a kolab server issue:
> 
> The CALDAV support in the kolab server doesn't report ACLs correctly.
> It says everyone has full access to everything, which prevents clients
> from handling readonly calendars correctly. E.g. I can add an event in
> a readonly calendar, it will fail to sync, and if I don't notice, this
> will lead to data loss in the long run, when re-setting up this client
> from scratch, for instance.
> 
> For a shared calendar which is readonly to me (and correctly shown as
> such in the roundcube GUI, with a small padlock icon), here's what the
> CALDAV XML says:
> 
> <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>
> ...
> These privileges are just wrong, can this be fixed so they are set
> correctly based on the IMAP ACLs ?
> Then client apps will be able to prevent users from making changes in
> these calendar folders, rather than letting data loss happen.
> 
> Thanks,