Bug 265096

Hi,

Thanks for reporting this issue. After some investigation the bug seems to lie in eGroupware: one of the XML elements of the response does not have the namespace set, and this causes it to be mis-detected. I've contacted the eGw devs with this info.

In the meantime you can set the '$cnrnd' variable to 'true' in the file 'egw-pear/HTTP/WebDAV/Server.php'.

I'll let this bug open to track the eGw devs answer and keep you informed.

Cheers,
Grégory

Hi Grégory,

Thank you for your reply.
I did the change as mentioned in my eGroupware installation and it is now working correctly.

Many thanks,

Joost

Hi Grégory,

in the moment I'm testing webdav under opensuse 11.3 the very new PIM 4.6 repo. Did the change under EGW 1.8 as you mentioned (...set the '$cnrnd' variable to 'true'....). Seems it woks fine now.

Thank You!!!

Wolf

This is also hapenning with google. Is this the same problem?

Hi Luis,

The issue with Google calendars is tracked here: https://bugs.kde.org/show_bug.cgi?id=272319 (it's now fixed).

Cheers,
Grégory

Hi Grégory,

this should be fixed with r35280-2 in all EGroupware branches in SVN, with the following fix:

Index: inc/class.groupdav.inc.php
===================================================================
--- inc/class.groupdav.inc.php	(Revision 35281)
+++ inc/class.groupdav.inc.php	(Arbeitskopie)
@@ -134,6 +134,7 @@
 		{
 			case 'kde':	// KAddressbook (at least in 3.5 can NOT subscribe / does NOT find addressbook)
 				$this->client_require_href_as_url = true;
+				$this->cnrnd = true; // Akonadi seems to require redundant namespaces, see KDE bug #265096 https://bugs.kde.org/show_bug.cgi?id=265096
 				break;
 			case 'cfnetwork':	// Apple addressbook app
 			case 'dataaccess':	// iPhone addressbook

Fix will be part of tomorrows daily 1.8 snapshot and the next maintenance release.

Ralf

Hi,

This issue is now fixed in eGroupware (see Ralf's message), and I confirm that I no longer can reproduce the issue.

Cheers,
Grégory

(In reply to comment #6)
> Hi Grégory,
> 
> this should be fixed with r35280-2 in all EGroupware branches in SVN, with the
> following fix:
> 
> Index: inc/class.groupdav.inc.php
> ===================================================================
> --- inc/class.groupdav.inc.php    (Revision 35281)
> +++ inc/class.groupdav.inc.php    (Arbeitskopie)
> @@ -134,6 +134,7 @@
>          {
>              case 'kde':    // KAddressbook (at least in 3.5 can NOT subscribe
> / does NOT find addressbook)
>                  $this->client_require_href_as_url = true;
> +                $this->cnrnd = true; // Akonadi seems to require redundant
> namespaces, see KDE bug #265096 https://bugs.kde.org/show_bug.cgi?id=265096
>                  break;
>              case 'cfnetwork':    // Apple addressbook app
>              case 'dataaccess':    // iPhone addressbook
> 
> Fix will be part of tomorrows daily 1.8 snapshot and the next maintenance
> release.
> 
> Ralf

Although the above fix is installed in my system, I needed to do the change suggeseted in comment #1 before kadressbook could use the eGroupware address source. Might get_handler() return something else than "kde", e.g. "kde4"? System is openSuSE 12.1 x86_64, eGroupware-1.8.002-20111111 from openSuSE Build Service.

Egbert

I can't get it working. I have eGroupware 1.8.002 and I confirmed I have the line from the patch above. I also tried setting $cnrnd to true in egw-pear/HTTP/WebDAV/Server.php. I still get Akonadi's error "Unable to fetch item from backend".

From akonadiconsole debugging:

KAddressBook::GlobalContactSession (0xa25a40) * 265 264 (NAME "Addressbook silver" MIMETYPE (text/directory) REMOTEID "https://myegroupware/groupdav.php/addressbook/" REMOTEREVISION "" RESOURCE "akonadi_davgroupware_resource_0" MESSAGES 13 UNSEEN 13 SIZE 2073 CACHEPOLICY (INHERIT true INTERVAL 10 CACHETIMEOUT -1 SYNCONDEMAND false LOCALPARTS ()) ANCESTORS ((264 "akonadi_davgroupware_resource_0") (0 "")) ENTITYDISPLAY "(\"\" \"view-pim-contacts\" \"\" ())" AccessRights "a" davprotocol "1") 
KAddressBook::GlobalContactSession (0xa25a40) * 264 0 (NAME "akonadi_davgroupware_resource_0" MIMETYPE (inode/directory) REMOTEID "akonadi_davgroupware_resource_0" REMOTEREVISION "" RESOURCE "akonadi_davgroupware_resource_0" MESSAGES 0 UNSEEN 0 SIZE 0 CACHEPOLICY (INHERIT false INTERVAL 10 CACHETIMEOUT -1 SYNCONDEMAND false LOCALPARTS ()) ANCESTORS ((0 "")) ENTITYDISPLAY "(\"eGroupware\" \"folder-remote\" \"\" ())") 
KAddressBook::GlobalContactSession (0xa25a40) 4 OK List completed 
KAddressBook::GlobalContactSession (0xa25a40) 5 SELECT SILENT 1 
KAddressBook::GlobalContactSession (0xa25a40) 5 OK Completed 
KAddressBook::GlobalContactSession (0xa25a40) 6 FETCH 1:* FULLPAYLOAD ANCESTORS INF EXTERNALPAYLOAD (UID REMOTEID REMOTEREVISION COLLECTIONID FLAGS SIZE DATETIME ATR:ENTITYDISPLAY) 
KAddressBook::GlobalContactSession (0xa25a40) 6 OK FETCH completed 
KAddressBook::GlobalContactSession (0xa25a40) 7 SELECT SILENT 268 
KAddressBook::GlobalContactSession (0xa25a40) 7 OK Completed 
KAddressBook::GlobalContactSession (0xa25a40) 8 FETCH 1:* FULLPAYLOAD ANCESTORS INF EXTERNALPAYLOAD (UID REMOTEID REMOTEREVISION COLLECTIONID FLAGS SIZE DATETIME ATR:ENTITYDISPLAY) 
KAddressBook::GlobalContactSession (0xa25a40) 8 OK FETCH completed 
KAddressBook::GlobalContactSession (0xa25a40) 9 SELECT SILENT 264 
KAddressBook::GlobalContactSession (0xa25a40) 9 OK Completed 
KAddressBook::GlobalContactSession (0xa25a40) 10 FETCH 1:* FULLPAYLOAD ANCESTORS INF EXTERNALPAYLOAD (UID REMOTEID REMOTEREVISION COLLECTIONID FLAGS SIZE DATETIME ATR:ENTITYDISPLAY) 
KAddressBook::GlobalContactSession (0xa25a40) 10 OK FETCH completed 
KAddressBook::GlobalContactSession (0xa25a40) 11 SELECT SILENT 265 
KAddressBook::GlobalContactSession (0xa25a40) 11 OK Completed 
KAddressBook::GlobalContactSession (0xa25a40) 12 FETCH 1:* FULLPAYLOAD ANCESTORS INF EXTERNALPAYLOAD (UID REMOTEID REMOTEREVISION COLLECTIONID FLAGS SIZE DATETIME ATR:ENTITYDISPLAY) 
KAddressBook::GlobalContactSession (0xa25a40) 12 NO Unable to fetch item from backend

It seems to be working in KDE 4.8.2. I haven't touched egw meanwhile though.