Moving from the users list to the developers list…
Do you have any patches in EGroupware sources?
Does that system uses PostgreSQL? Maybe that’s an unwanted side-effect.
Have you been to setup, are there any pending updates?
Please post the schema of egw_addressbook or check if it contains a
carddav_name column.
My EGroupware installation contains no patches any longer as you have
resolved any of the issues I have found in the past. I do use
PostgreSQL, but all of my accounts and contacts are stored in LDAP.
Ok, that’s the problem, CardDAV access is NOT supported for contacts in
LDAP
Some support should be easy to get (like fixing the missing name-part),
full support would require an own LDAP schema to store things like a
name-part of the url a client can specifiy or etags.
Performance will be bad, as we cant have real ctags, without reading all
contacts, to get the maximum modification time. Might not be as bad, as
LDAP works currently in EGroupware only with small addressbooks anyway.
Hugh addressbooks with ten-thousands of contacts will be a pain.
I have a mail here from a user with a patch for that, thought it’s in
German. If you want I can forward it to you. I dont have time currently
to fix it
Ralf
Ralf, the patches you sent inspired me to dig a bit into GroupDAV with
LDAP contacts. It appears that the ETag is already working properly,
etc. and that the problem was related to the GroupDAV handler not
setting the URL properly for each entry–each entry was simply mapped to
/addressbook/, since there is no carddav_name column.
If the groupdav_handler::$path_attr is mapped to ‘uid’ instead of
’carddav_name’, then everything works properly. See the patch below.
I realize that this isn’t the “right” way to fix the problem, but
perhaps someone can point me in the right direction based on the small
changes below which allow GroupDAV with contacts in LDAP to work just fine.
- I first tried adding the following to class.addressbook_ldap.inc.php
with no modifications to class.addressbook_groupdav.inc.php:
‘inetorgperson’ => array(
‘carddav_name’ => ‘uid’,
and while this set the proper URLs for download, I always received a 403
error from the client when trying to download an single entry (which had
a url of
…/egroupware/groupdav.php/addressbook/c7fe138d24282fabbd13da2324e7450c)
- I then modified class.addressbook_groupdav.inc.php to
groupdav_handler::$path_attr = ‘uid’;
and everything worked. This patch is based on trunk@38201. Any help is
appreciated. Thanks. -A
diff --git a/addressbook/inc/class.addressbook_groupdav.inc.php
b/addressbook/inc/class.addressbook_groupdav.inc.php
index 6861a12…fcd9360 100644
— a/addressbook/inc/class.addressbook_groupdav.inc.php
+++ b/addressbook/inc/class.addressbook_groupdav.inc.php
@@ -74,7 +74,8 @@ class addressbook_groupdav extends groupdav_handler
// since 1.9.007 we allow clients to specify the URL
when creating a new contact, as specified by CardDAV
if
(version_compare($GLOBALS[‘egw_info’][‘apps’][‘phpgwapi’][‘version’],
‘1.9.007’, ‘>=’))
{
+// groupdav_handler::$path_attr = ‘carddav_name’;
diff --git a/addressbook/inc/class.addressbook_ldap.inc.php
b/addressbook/inc/class.addressbook_ldap.inc.php
index 69404db…b60a6fe 100644
— a/addressbook/inc/class.addressbook_ldap.inc.php
+++ b/addressbook/inc/class.addressbook_ldap.inc.php
@@ -84,6 +84,7 @@ class addressbook_ldap
’account_lid’ => ‘uid’,
),
‘inetorgperson’ => array(
-
'uid' => 'uid',
'n_fn' => 'cn',
'n_given' => 'givenname',
'n_family' => 'sn',
–
Anthony - http://messinet.com - http://messinet.com/~amessina/gallery
8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E