Page MenuHomePhorge

Show CardDAV URL also for GAL
Closed, ResolvedPublic3 Story Points

Description

Currently, only IMAP-based address books allow their respective CardDAV URL to be shown in the web app by using the $config['kolab_addressbook_carddav_url'] variable. LDAP-based address books have this function greyed out and currently do not support it.

The URL for them is constructed with:

/addressbooks/<user-email>/ldap-directory/

Currently, it is not documented how to access the GAL via CardDAV. Using this already existing Show URL feature, would be good way to do it.

However, for various reasons, we can not fully support this feature, so the configuration option should include a big fat comment to that extent and tell users to only enable this feature if they are ready to deal with the fall-out.

Details

Ticket Type
Task

Event Timeline

grote raised the priority of this task from to 60.
grote updated the task description. (Show Details)
grote changed Ticket Type from Task to Task.
grote subscribed.
petersen subscribed.

Taking this out of the server sprint 201520, as that sprint has been dedicated to setting up test facilities.

grote edited a custom field.
grote added a project: Restricted Project.Jun 17 2015, 11:10 AM
grote lowered the priority of this task from 60 to 40.Jun 17 2015, 2:29 PM
grote moved this task from Ready for Sprint to In Sprint on the Product Owners board.
grote edited projects, added Restricted Project; removed Restricted Project.
grote edited projects, added Restricted Project; removed Restricted Project.Jul 15 2015, 2:11 PM

I'm not aware of the "various reasons, we can not fully support this feature". Could you elaborate/provide the warning text?

Roundcube allows more than one LDAP addressbook, as I see iRony supports only one ("ldap-directory"). So, I suppose this is the one limitation. Do we need a new configuration option that will give the user possibility to assign any ldap addressbook and enable the URL feature for only this one?

machniak edited a custom field.

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.

Other than that, the ldap-directory exposed in iRony is strictly read-only. Although correctly stated in den CardDAV properties, some clients (e.g. the SoGO connector) ignore these properties and allow modifications which then result in sync errors because the server denies such updated.

I assume these are the things the users should be warned about but please let @grote answer that.

For the implementation, I suggest to add an option to the kolab_addressbook plugin config, that specifies the one LDAP address book (key of the ldap_public config) which should show the CardDAV url menu item.

Thanks a lot @bruederli for explaining the limitations!

I think this makes for a perfect warning text to be added as a comment into the config file:

WARNING: There's limitations with 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.

Other than that, the ldap-directory exposed in iRony is strictly read-only. Although correctly stated in the CardDAV properties, some clients (e.g. the Thunderbird SoGO connector) ignore these properties and allow modifications which then result in sync errors because the server denies such updates.

machniak moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Jul 28 2015, 4:54 PM
machniak moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.

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.