View Issue Details

IDProjectCategoryView StatusLast Update
0002575SOGo Connectorwith SOGopublic2018-06-18 04:32
Reporterfarson Assigned Toludovic  
PriorityimmediateSeveritymajorReproducibilityalways
Status closedResolutionsuspended 
PlatformWindowsOSOS Version7
Product Version 
Target VersionFixed in Version 
Summary0002575: TB fails to update an existing contact via CardDAV
DescriptionThunderbird: 24.2.0
Inverse SOGo Connector Thunderbird 24.0.2 (released on November 22nd 2013)
Baïkal 0.2.6
Android: CardDAV sync (multiple clients)
Betriebssystem + Version: Windows 7


Thunderbird has problems updating an existing contact via the CardDAV protocol.
Steps To ReproduceExact Steps to reproduce:

Have Thunderbird 24.2.0 with Inverse SOGo Connector 24.0.2 and Baïkal 0.2.6
As well as one other (e.g.) Android client syncing via CardDav.

-Generate a NEW contact (e.g. "Kontakt TB3") in TB addressbook, enter a private phone number.
-Sync addressbook with other client, checking new Kontakt TB3 has appeared.
-Then Go back to Thunderbird and edit existing Contact "Kontakt TB3" by changing the private phone number. Click OK to Save.
-Make sure a Sync is performed again.

 => Contact is NOT updated on other clients (e.g. CardDav sync on Android).

Conclusion:
Hence Thunderbird has problems updating an existing contact via the CardDAV protocol.

Is there a workaround for that?
Additional InformationThunderbird: 24.2.0
Inverse SOGo Connector Thunderbird 24.0.2 (released on November 22nd 2013)
Baïkal 0.2.6
Android: CardDAV sync (multiple clients)
Betriebssystem + Version: Windows 7


Thunderbird has problems updating an existing contact via the CardDAV protocol.
TagsNo tags attached.

Activities

JSB

JSB

2014-01-14 16:24

reporter   ~0006390

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.
farson

farson

2014-01-14 17:51

reporter   ~0006391

@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!
ludovic

ludovic

2014-01-14 17:56

administrator   ~0006392

Try with a nightly build of SOGo Connector:

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

JSB

2014-01-14 22:34

reporter   ~0006393

Last edited: 2014-01-14 22:39

View 2 revisions

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.

farson

farson

2014-01-15 05:46

reporter   ~0006394

@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!
CATER

CATER

2014-01-15 16:30

reporter   ~0006401

@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.
JSB

JSB

2014-01-16 09:05

reporter   ~0006404

@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?
farson

farson

2014-01-17 18:13

reporter   ~0006409

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)?
ludovic

ludovic

2014-01-23 05:48

administrator   ~0006421

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

elbenfreund

2014-02-09 20:59

reporter   ~0006538

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)
ludovic

ludovic

2014-02-09 21:02

administrator   ~0006539

Try the latest version for v24 here:

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

There will be no updates for v17.
fbugs

fbugs

2014-02-16 15:45

reporter   ~0006547

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.
JSB

JSB

2014-03-14 14:27

reporter   ~0006709

(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.
timreeves

timreeves

2014-04-22 11:11

reporter   ~0006946

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
timreeves

timreeves

2014-04-22 12:56

reporter   ~0006947

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
fmjrey

fmjrey

2014-08-28 09:30

reporter   ~0007444

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!
unilineitsupport

unilineitsupport

2014-10-09 07:06

reporter   ~0007595

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?
lje

lje

2016-01-12 09:12

reporter   ~0009272

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.
jobisoft

jobisoft

2016-04-27 16:52

reporter   ~0010028

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.
ludovic

ludovic

2016-05-20 14:44

administrator   ~0010195

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.

Issue History

Date Modified Username Field Change
2014-01-13 13:59 farson New Issue
2014-01-14 16:24 JSB Note Added: 0006390
2014-01-14 17:51 farson Note Added: 0006391
2014-01-14 17:56 ludovic Note Added: 0006392
2014-01-14 22:34 JSB Note Added: 0006393
2014-01-14 22:39 JSB Note Edited: 0006393 View Revisions
2014-01-15 05:46 farson Note Added: 0006394
2014-01-15 16:30 CATER Note Added: 0006401
2014-01-16 09:05 JSB Note Added: 0006404
2014-01-17 18:13 farson Note Added: 0006409
2014-01-23 05:48 ludovic Note Added: 0006421
2014-02-09 20:59 elbenfreund Note Added: 0006538
2014-02-09 21:02 ludovic Note Added: 0006539
2014-02-16 15:45 fbugs Note Added: 0006547
2014-03-14 14:27 JSB Note Added: 0006709
2014-04-22 11:11 timreeves Note Added: 0006946
2014-04-22 12:56 timreeves Note Added: 0006947
2014-08-28 09:30 fmjrey Note Added: 0007444
2014-10-09 07:06 unilineitsupport Note Added: 0007595
2016-01-12 09:12 lje Note Added: 0009272
2016-04-27 16:52 jobisoft Note Added: 0010028
2016-05-20 14:44 ludovic Note Added: 0010195
2016-05-20 14:44 ludovic Status new => closed
2016-05-20 14:44 ludovic Assigned To => ludovic
2016-05-20 14:44 ludovic Resolution open => suspended