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.

Roundcube core and kolab_addressbook plugin does not support photo URLs. It is not clear to me if it is at all possible to store URL and mediatype in Kolab XML format (probably only URL without type is supported).

The same as in syncroton (T1751) it is caused by authentication cache.

DAVBackend::folder_create() returns false on error, but it should throw an exception.

Diff created. I didn't find a nice way to avoid imap_debug issue described in my comment above. There are two sides of this issue though:

• user id/name is not set before user is authenticated. That's why some part of logs go to logs/ directory instead of logs/<username>/. I found a workaround, but a little bit hacky. In DAVLogger::_construct() add:

$_SESSION['username'] = $_SERVER['PHP_AUTH_USER'];
$_SESSION['user_id']      = -1;

this however requires to login with canonified username, if you use alias for login and canonified username for logs dir it will not catch up.
Anyway this is not a big issue, as most relevant logs are written on after auth.

• should logs/imap file (and others) be created at all if per_user_logging=true? I mean that's current behaviour, but changing this would allow as to have all debug options enabled with per_user_logging and get logs only for set up users.

And related to this, enabling e.g. imap_debug together with any of above options does not really work as expected, i.e. the whole imap conversation from after login goes where expected, but everything before the user has been authenticated goes to logs/imap. Maybe it would be possible to fix this by setting $_SESSION['username'] before loging into imap.

Is this related to why setting a picture for a contact in Android fails when syncing with DAVdroid? Should another bug be filed for that?

Fixed the initial issue. I could not find a reproduceable test case, but the fix is really simple and the same check is used few lines before.

All the tests which are in the iRony repository used to run through without errors. So if that changed on Winterfell, it should be looked at.

I recently run iRony's tests on Kolab Winterfell, and it gave me 14 failed tests. It looks like we don't really use these for CI, are we?

Also, adding the TYPE attribute in v3 seems a reasonable change to me.

Yes, Apple clients also use "b" when exporting and synching contact photos although they can handle upper-cased values as well. But the way to go definitely is lower-cased.

In T1082#16053, @machniak wrote:

"B" and "b" both work with iOS7 Contacts app.

"B" and "b" both work with iOS7 Contacts app.

This broke in my recent performance improvements in libkolab plugin code. https://git.kolab.org/rRPK52053f355af6c09db547f1b8d02bb9ae88abcb1c So, it's Winterfell only.

In T1082#15730, @vanmeeuwen wrote:

Perhaps it has come from section 2.4.1?

Perhaps it has come from section 2.4.1?

Please create a ticket for this differential, and set the summary of this differential to "Resolves T$x", where $x is the ticket number you get.

I don't recall where that change came from and I can't find an according test/sample case. We should comply with RCF here.

As this contradicts with rId20afc78222279, would be nice to have feedback from Thomas.

That's a different issue. Probably fixed by this https://git.kolab.org/rIbb534210020c5fedd9c4b780c995e8b7c20d81a6

The error remains.

Patched the internal webservers, @vincent is testing.

The Sabre/VObject is in version 2.1.7, so it should be fine.

BTW: Still seeing these after the recent Kolab Now service window. Should it have resolved them or is this something new/residual?

Also not reproducable with current KE14 - iRony DAV Server 0.2.8SabreSabre VObject 2.1.3.