Included in pykolab-0.7.15.

I have made the first proposed change, however the explanation about SPF records can not be done easily as proposed, because the values are just read out of the configuration file in a loop without the possibility to inject further text.

Here's the whiteboard from a feature session:

Hmm... I'm not so sure. According to RFC5545 it is not valid.

Fixed also some Kolab plugins issues. I consider this ticket issue fixed.

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

I'm unable to reproduce the initial issue in Kolab:Development. The TRIGGER property is not broken when importing ics using iRony and then exporting it there.

Oops. It looks that "P" is valid. I'll look for the issue in other places.

I found it's libkolabxml issue, see T670. However, some code alignments and workarounds still needed in libkolab and libcalenaring plugins.

1. kolab-syncroton does not support Reminder=0 now, need to be fixed.
2. There are issues in Roundcube UI. While you can set alarm to "0" when you visit the event again there are small glitches in the alarm description and edit field. The reminder message is not displayed.

BTW, when adding such event via Roundcube the TRIGGER is correctly saved as -PT0M. So, it looks that iRony/SabreDAV is doing something wrong here.

Yes, it does.

Does this also support different authentication credentials per user to one external WebDAV server like with SeaFile?

It's maybe also worth to notice that enabling this feature may severely influence the load on the Kolab server. Reason: every time a client want to synchronize, it requests the change state of the collection from the server. With an LDAP directory, the only way to compile the change state is to read every single record in the directory and return the last modification date.

Thanks a lot @bruederli for explaining the limitations!

The limitations are probably more down to volume and performance. CardDAV does a full sync of the entire contact resource. For LDAP this means that all entries matching the base_dn/filter are synced to every client. It's thus only recommended for small setups with a couple hundred LDAP entries.

Please, review.

Agreed about the /private namespace. This is fixed by above commit. The problem is with priority of the other two annotations. As I said, iRony (actually only iRony uses these methods) depends on the fact that we can set a folder ID to defined value. So, if we set "kolab" annotation to something and the use "cyrus" annotation we have a problem. That's why I left the order as it was before. See the commit. Tell me if you see this different.

In T491#8369, @machniak wrote:

So, it looks like we need to check the /shared/vendor/kolab/uniqueid annotation first and fallback to cyrus annotation if it does not exists in get_uid().

We can't give a prio to cyrus uniqueid annotation. I've found iRony's Kolab/Utils/DAVBackend.php code which (beside unsused class constants) sets folder UID and, I assume, the DAV client expects the same UID to be used later. So, it looks like we need to check the /shared/vendor/kolab/uniqueid annotation first and fallback to cyrus annotation if it does not exists in get_uid().