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.

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;

Hallo machniak,

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?

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

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

In T1141#17069, @machniak wrote:

This scenario is not possible at the moment and because SeaFile has it's own WebDAV service I'm not sure there's a need to use iRony for that. You can configure iRony to provide CalDAV and CardDAV only if needed.

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

We might need to store the original URL-ID of the contact object to be able to handle DELETE requests.

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

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.

@bruederli Do you remember what's the reason for https://git.kolab.org/source/iRony/browse/master/lib/Kolab/CalDAV/CalendarBackend.php;ead6159e01eb2b44b9f90665d17168cd14f5ce3b$91 to be not active?

Fixed by 0c02d0d45c6 in roundcubemail-plugins-kolab [master].

I verified with the code that if the original event would specify SCHEDULE-AGENT=CLIENT for the attendee it would be properly recognized by SabreDAV classes and the CANCEL would not be sent. So, what we need is to store this initial SCHEDULE-AGENT value in custom properties of Kolab format (or extend the format of https://wiki.kolab.org/User:Mollekopf/Drafts/KEP:17#Attendee).

Could be. I've tried to create new meeting and looking at the Caldav I see that ATTEDEE is:

ATTENDEE;CN=ks@fsi.io;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:
 mailto:ks@fsi.io

So looks like SCHEDULE-AGENT is gone.

However, https://tools.ietf.org/html/rfc6638#section-3.2.1.2 says that CANCEL is sent when an event was modified and previous scheduling was done by the server (default if SCHEDULE-AGENT is not specified). So, probably the issue is in recognizing the previous state.

Fixed.

Fixed.

Fixed.

Hard to say it's deployment or code issue and it's old. Closing.

To reproduce the issue just try to rename a file over WebDAV.

I came across this issue yesterday and the above patch appears to fix the problem for me. Please merge it into the iRony repository.

I'm unable to reproduce this with Roundcube Calendar. So, it might be already fixed or the bug is in iRony.