Bug 97802 - Syncevolution CardDAV syncing Cpanel accounts instead of Horde addressbook
Summary: Syncevolution CardDAV syncing Cpanel accounts instead of Horde addressbook
Status: RESOLVED NOTABUG
Alias: None
Product: SyncEvolution
Classification: Unclassified
Component: CalDAV/CardDAV (show other bugs)
Version: 1.5
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Patrick Ohly
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-09-14 07:37 UTC by powersurge69
Modified: 2016-09-19 09:23 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
Output from debug command (23.60 KB, text/plain)
2016-09-14 08:35 UTC, powersurge69
Details
Updated output from debug command (70.57 KB, text/plain)
2016-09-14 17:22 UTC, powersurge69
Details

Description powersurge69 2016-09-14 07:37:18 UTC
I used the following commands to set up Syncevolution to sync my Horde addressbook under my Cpanel account.

$ syncevolution --configure --template webdav syncURL=https://{hosturl}:2080/ username={emailaddress} password={password} target-config@webdav

$ syncevolution --configure --template SyncEvolution_Client syncURL=local://@webdav username= password= webdav calendar addressbook todo

$ syncevolution --sync refresh-from-remote webdav

Of course I changed {hosturl}, {emailaddress}, and {password} to what would work with my host and everything syncs properly except for the addressbook, which only syncs my Cpanel user accounts and not my Horde addressbook.  I first emailed my host and they told me that this would be caused by setting up my sync client with my Cpanel account instead of my webmail account, but I was using my webmail account.  I then tried using an older version of Syncevolution (1.4) and it synced all of my Horde addressbook perfectly, so something changed in 1.5 that is causing Syncevolution to sync the wrong contacts under Cpanel.
Comment 1 Patrick Ohly 2016-09-14 08:10:00 UTC
Something in the updated database scanning in 1.5 probably causes this.

Can you run the following command and attach the output?

SYNCEVOLUTION_DEBUG=1 syncevolution --daemon=no --print-databases loglevel=10 backend=carddav syncURL=https://{hosturl}:2080/ username={emailaddress} password={password}

I suspect that it'll find multiple suitable address books and just happens to pick the wrong one as default. You can override that with:

syncevolution --configure database={URL printed by --print-databases} @webdav addressbook
Comment 2 powersurge69 2016-09-14 08:35:14 UTC
Created attachment 126511 [details]
Output from debug command

Part of the output got cut off because I could only scroll back so far.
Comment 3 powersurge69 2016-09-14 09:01:57 UTC
So I entered the following:

$ syncevolution --print-databases syncURL=https://{hosturl}:2080/ username={emailaddress} password={password}

and this gave me the URL. I then entered:

$ syncevolution --configure database={URL from above}/ @webdav addressbook
$ syncevolution --configure --template SyncEvolution_Client syncURL=local://@webdav username= password= webdav calendar addressbook todo
$ syncevolution --sync refresh-from-remote webdav

and my Horde addressbook synced perfectly! Thank you for your assistance! :)
Comment 4 Patrick Ohly 2016-09-14 09:51:52 UTC
Please collect a log with:

SYNCEVOLUTION_DEBUG=1 syncevolution --daemon=no --print-databases loglevel=4 backend=carddav syncURL=https://{hosturl}:2080/ username={emailaddress} password={password} >/tmp/log 2>&1

loglevel=4 has enough information, 10 isn't needed.

I'd still like to have a look why the expected collection isn't chosen as default.
Comment 5 powersurge69 2016-09-14 17:22:07 UTC
Created attachment 126523 [details]
Updated output from debug command
Comment 6 Patrick Ohly 2016-09-19 09:23:10 UTC
It's as I thought: both address books are contained underneath /rpc/addressbooks/{emailaddress}/ and there's nothing that tells SyncEvolution which one is "more important". Therefore it picks the one listed first by the server, which happens to be the one which wasn't intended.

I'm not sure why that worked with 1.4, but the database scanning was changed to fix other problems, so reverting isn't an option.

I'm afraid manually checking the default and overriding it as describe before indeed seems to be the only solution for this.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.