Confirmed.

I noticed the exact same problem on my configuration:

Thunderbird: 24.2.0 on Windows 7 and Linux Mint 13
Inverse SOGo Connector Thunderbird 24.0.2
ownCloud 5.0.14a running on SME Server 8.0
Android Contact Sync on my tablet

Results of tests between Thunderbird, ownCloud, and my Android tablet:

Adding and deleting contacts propagate properly between all three.
Changing a contact on the tablet or the server updates the other but NOT Thunderbird.

Likewise, changes to an existing contact on Thunderbird do not propagate to the tablet or to the server. Nor does Thunderbird receive changes to a contact made by the other two.

Conclusion: The SOGo Connector is synchronizing CardDAV adds and deletes, but not changes.

@JSB:
I also did the test against ownCloud 5.0.10.

Absolutely reproducible.

I am not a programmer myself, but I would be happy if the Tb-Sogo developers could look into that.
With the situation as is, CardDAV sync remains absolutely unreliable!

Try with a nightly build of SOGo Connector:

https://inverse.ca/downloads/extensions/nightly/

Still quirky.

With the latest nightly, sometimes changes propagate, sometimes they don't.

Thinking that I might have some contacts that had differing changes on both sides, I decided to start fresh. I started with a smaller subset of my contacts in Thunderbird and synchronized with the server. Out of 300 Contacts, only 282 uploaded. I located one of the contacts that didn't upload, made a minor edit, and synchronized again. This time, the contact uploaded.

With over 1000 contacts in my full list, finding the ones that don't feel like going just to give them a nudge is...daunting.

@ludovic:

When do you think this issue can be regarded as "solved" in a stable version (in case you are or have contact to active development)?

We need to install Tb with such CardDAV sync on multiple machines.

Thank you!

@farson

I noticed yesterday the same problem during installation with Thunderbird: 24.2.0 on Windows 7 and Inverse SOGo Connector 24.0.2.

My config was working but for my collegue not. My TB was connected to ownCloud 6 with SOGo Connector 17.0.5.

Changing SOGo Connector 24.0.2 to SOGo Connector 17.0.5 solved the problem until the issue will be fixed in a next stable release.

@CATER

Changing to SOGo Connector 17.0.5 was one of the first things I tried. Unfortunately, it did not resolve the issue for me. Perhaps 17.0.5 plays better with ownCloud 6 versus ownCloud 5?

The nighty built sogo-connector-24.0.2-d1b32b9789.xpi
seems to have sorted the problem for me.

@ludovic:

When do you think this issue can be regarded as "solved" in a stable version (in case you are or have contact to active development)?

In the upcoming SOGo v2.2 release, next week.

were you able to fix just the recent sogo-connector-24.0.2-d1b32b9789.xpi or the 17.0.6 as well?

17.0.6 still seems to suffer from this bug as of now.
(TB 17, debian wheezy)

Try the latest version for v24 here:

http://www.inverse.ca/downloads/extensions/nightly/

There will be no updates for v17.

I tried the latest version for v24 from nightly, but I cannot confirm that this is fixed (using mykolab server).

Additional note: I only see the described behavior when I add the new contact in the TB address book. After doing so, an edit in the TB address book will not be synchronized. If I add the contact e.g. using Android address book, and then edit this same contact in TB address book after it has propagated there, the changes are synchronized properly.

(Sigh).

The sogo-connector-24.0.4.xpi 24-Feb-2014 20:35 255K release spontaneously (and randomly) creates contact duplicates. And triplicates. And more.

Nightly version sogo-connector-24.0.4-6c8ee8bcc2.xpi is also erratic. Sometimes contact changes propagate, sometimes they don't. Sometimes new contacts propagate, sometimes they don't. VERY frustrating when I'm out on the road and a vital contact is NOT in my address book.

Does anyone still have a copy of nightly version sogo-connector-24.0.2-d1b32b9789.xpi that I could try (since farson mentioned that it sorted the problem for him)? I really need this to start working properly, reliably, and consistently ASAP.

I originally posted the following text to GitHub, as a comment to an existing issue; now, the whole "Issues" section at GitHub seems to have vanished )-:

So here my text again - in regard of 24.0.2, I will check 24.0.4 next thing.

Yes, this is an ETag problem which I have also encountered.

I edited a contact in eGroupware (Serverside) and in Thunderbird Addressbook.
Trying to update the Server, SOGo keeps sending: If-Match: "100:5", which is the ETag value provided when storing the contact from the server.
But on the server side, the ETag of the contact has already been bumped up to "100:7", causing eGroupware to correctly reject the update (412 Precondition Failed).
So one cleverly thinks "Ah I'll get them back into Sync by forcing a Sync in SOGo to the Server status", one manually starts a Sync. SOGo fetches the Sync data from the server, including:

<D:response xmlns:ns0="urn:uuid:c2f41010-65b3-11d1-a29f-00aa00c14882/">
<D:href>/egroupware/groupdav.php/shunyata/addressbook/C5D4AF59-3810-0001-414B-10521FB034A0.vcf</D:href>
<D:propstat>
<D:prop>
<D:getcontenttype>text/vcard</D:getcontenttype>
<D:getetag>"100:7"</D:getetag>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>

Although the ETag of this contact (see href field) is correctly given as "100:7", SOGo seems not to notice this, and instead, at the end of the Sync run
again proffers a PUT with its outdated update: If-Match: "100:5", which is patently going to fail.

BTW If you don't perform any updates at the server, always only in Thunderbird, then it works - eGroupware keeps incrementing the ETag value - as it should -
but SOGo never sends an If-Match, as it apparently has never received (or noted) an ETag value from the Server.

If anyone needs the SVN 2013-12-09 version from Jonathan deBoer, then get it here: http://lasslos.net/sogo-connector-24.0.2a.xpi

I have now tested 24.0.4 as promised:

Add new contact in Thunderbird: OK
Modify contact in Thunderbird: OK
Modify contact on Server (eGroupware) + manual sync in Thunderbird: OK
Modify contact 1st on Server 2nd in Thunderbird: Server wins - but SC from then on keeps trying to sync the contact, which is most annoying, IMHO it should give up and accept the server version
Delete contact on Server + manual sync in Thunderbird: Now SC uploads the contact to the server - not convinced that's what we want...
Delete contact in Thunderbird: OK, deleted on server too.

Add new contact on Server + manual sync in Thunderbird: OK
Modify contact in Thunderbird: OK
Delete contact on Server + manual sync in Thunderbird: OK, deleted in Thunderbird
There is a small bug in the notifier (Win 8.1): "0 uploaded, 0 downloaded,"
The message part re the deletion was missing or not visible.

I have not (yet) observed the duplicates problem noted above by JSB. Perhaps it had to do with the conflicting ETag value problem noted in this post, whereby SOGo connector does not give up and let the server win.

So I think what is needed is a config option:

In case of conflicting updates: O Server wins O Thunderbird wins

I think I have the same issue using Thunderbird 31 + Sogo Connector 24.0.6 + Owncloud 7.0.2 on Ubuntu 12.04 64bits.
Some contact in Thunderbird don't propagate changes on the server, but others do. It's always the same contacts that don't sync while others do. I see no error anywhere, so I used Wireshark to sniff traffic and noticed that when SoGo tries to get the etag after sending the PUT request it's always getting the same value from the server. So the server does not update anything, and Sogo does not say anything either.
I think this needs to be reported to the user, and if there is a conflict or an update that does not work, it also needs to be brought to the user's attention, and ideally one should be able to decide which version should prevail.
My encouragement to get this fixed soon, thanks!

Hello,

I was also playing with SogoConnector 24.0.4 and 24.0.7.
I am using BAIKAL for carddav. Since sogo is using VCARD3 format.

Updates are made on the server, deleted, added cards, updates cards etc.
They are not synced after manual/automatic syncronize command in TB.

They only get synced after you recreate the remote addressbook. But i also
noticed when you do a following.

1. Export cards from server / backup / not on machine with tb/sogo
2. delete all contacts from remote addressbook manually with select all and delete.
3. addressbook is empty. delete command passed to server. no data.
4. import cards back to server /not on machine with tb/sogo
5. do manual sync
6. contacts come back / almost the same as recreate

this is not fixed in latest version?

ps. how does the connector know or read modifications? what can i test?

It's been 2 years since this bug was reported, over one year after the last update and it is still not fixed :-(

Thunderbird 38, SoGo connector 31.0.2.

Create new contact => sync works
Change telephone number of existing contact => no sync
Change birthday of existing contact => no sync

Will this ever be fixed?
So far SOGo connector seems to be the only real CardDAV addon for TB.

I would like to point out, that with TB38 the new "global" or "merged" addressbook has been introduced.

If that global addressbook is selected, changes to a contact are not synced (not even triggered, as nothing is happening on the TB -console).

If a true groupdav addressbook is selected, syncing is working as expected.

Tested today with TB45, SOGo Connector 31.0.2 and Owncloud 8.2.3.

Suspending - reports that everything is now working.

Make sure you also test 31.0.3. If there is any other issue related to this bug, reopen it.