3. SOGo 2.3.3a doesn't report contacts without email address

SOGo 2.3.3a doesn't report contacts without email address

  • S

    So I created two contacts.

    BEGIN:VCARD
UID:5281-5657B880-1-2C1A198.vcf
VERSION:3.0
CLASS:PUBLIC
PROFILE:VCARD
N:;Joe Bloggs
FN:Joe Bloggs
EMAIL;TYPE=work:joeblogs@example.com
END:VCARD

    and:

    BEGIN:VCARD
UID:530C-5657B900-1-2A2FE6C0.vcf
VERSION:3.0
CLASS:PUBLIC
PROFILE:VCARD
N:;Sally Bloggs
FN:Sally Bloggs
END:VCARD

    The full debug log is here:

    [info ] Preparing synchronization
[info ] Querying capabilities
[trace] --> PROPFIND /SOGo/dav/fred@bloggsfamily.id/Contacts/personal/ HTTP/1.1
[trace] Depth: 0
[trace] <?xml version='1.0' encoding='UTF-8' ?><propfind xmlns="DAV:" xmlns:CAL="urn:ietf:par\
[trace] ams:xml:ns:caldav" xmlns:CARD="urn:ietf:params:xml:ns:carddav"><prop><CARD:supported-\
[trace] address-data /><n0:getctag xmlns:n0="http://calendarserver.org/ns/" /></prop></propfi\
[trace] nd>
[trace] --> END PROPFIND (258-byte body)
[trace] <-- HTTP/1.1 207 Multi-Status (1525ms)
[trace] Server: nginx
[trace] Date: Fri, 27 Nov 2015 02:28:08 GMT
[trace] Content-Type: text/xml; charset="utf-8"
[trace] Content-Length: 478
[trace] Connection: keep-alive
[trace] X-Dav-Error: 200 No error
[trace] Ms-Author-Via: DAV
[trace] Pragma: no-cache
[trace] Cache-Control: no-cache
[trace] OkHttp-Selected-Protocol: http/1.1
[trace] OkHttp-Sent-Millis: 1448591287577
[trace] OkHttp-Received-Millis: 1448591287974
[trace] <?xml version="1.0" encoding="utf-8"?>
[trace] <D:multistatus xmlns:a="urn:ietf:params:xml:ns:carddav" xmlns:D="DAV:" xmlns:b="http:\
[trace] //calendarserver.org/ns/"><D:response><D:href>/SOGo/dav/fred@bloggsfamily.id/Contacts/p\
[trace] ersonal/</D:href><D:propstat><D:status>HTTP/1.1 200 OK</D:status><D:prop><b:getctag>1\
[trace] 448591266</b:getctag></D:prop></D:propstat><D:propstat><D:status>HTTP/1.1 404 Not Fou\
[trace] nd</D:status><D:prop><a:supported-address-data/></D:prop></D:propstat></D:response></\
[trace] D:multistatus>
[trace] <-- END HTTP (478-byte body)
[debug] Received <response> for https://sogo.myserver.com/SOGo/dav/fred@bloggsfamily.id/Contacts/personal/, status: null, properties: [getctag(http://calendarserver.org/ns/): GetCTag(cTag=1448591266),
supported-address-data(urn:ietf:params:xml:ns:carddav): null]
[info ] Server advertises VCard/4 support: false
[info ] Processing locally deleted entries
[info ] Locally preparing dirty entries
[info ] Uploading dirty entries
[info ] Checking sync state
[info ] Manual sync, ignoring CTag
[info ] Listing local entries
[debug] Found local resource: 5281-5657B880-1-2C1A198.vcf
[debug] Found local resource: 530C-5657B900-1-2A2FE6C0.vcf
[info ] Listing remote entries
[trace] --> REPORT /SOGo/dav/fred@bloggsfamily.id/Contacts/personal/ HTTP/1.1
[trace] Depth: 1
[trace] <?xml version='1.0' encoding='UTF-8' ?><CARD:addressbook-query xmlns="DAV:" xmlns:CAR\
[trace] D="urn:ietf:params:xml:ns:carddav"><prop><getetag /></prop><CARD:filter /></CARD:addr\
[trace] essbook-query>
[trace] --> END REPORT (184-byte body)
[trace] <-- HTTP/1.1 207 Multi-Status (385ms)
[trace] Server: nginx
[trace] Date: Fri, 27 Nov 2015 02:28:08 GMT
[trace] Content-Type: text/xml; charset="utf-8"
[trace] Content-Length: 761
[trace] Connection: keep-alive
[trace] Cache-Control: no-cache
[trace] Pragma: no-cache
[trace] OkHttp-Selected-Protocol: http/1.1
[trace] OkHttp-Sent-Millis: 1448591288114
[trace] OkHttp-Received-Millis: 1448591288487
[trace] <?xml version="1.0" encoding="utf-8"?>
[trace] <D:multistatus xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:carddav"><D:response><D\
[trace] :href>/SOGo/dav/fred@bloggsfamily.id/Contacts/personal/5281-5657B880-1-2C1A198.vcf</D:h\
[trace] ref><D:propstat><D:prop><D:getetag>"gcs00000000"</D:getetag><C:address-data>BEGIN:VCA\
[trace] RD
[trace] UID:5281-5657B880-1-2C1A198.vcf
[trace] VERSION:3.0
[trace] CLASS:PUBLIC
[trace] PROFILE:VCARD
[trace] N:;Joe Bloggs
[trace] FN:Joe Bloggs
[trace] EMAIL;TYPE=work:joeblogs@example.com
[trace] END:VCARD</C:address-data><C:addressbook-data>BEGIN:VCARD
[trace] UID:5281-5657B880-1-2C1A198.vcf
[trace] VERSION:3.0
[trace] CLASS:PUBLIC
[trace] PROFILE:VCARD
[trace] N:;Joe Bloggs
[trace] FN:Joe Bloggs
[trace] EMAIL;TYPE=work:joeblogs@example.com
[trace] END:VCARD</C:addressbook-data></D:prop><D:status>HTTP/1.1 200 OK</D:status></D:propst\
[trace] at></D:response></D:multistatus>
[trace] <-- END HTTP (761-byte body)
[debug] Ignoring unknown/unparseable property addressbook-data(urn:ietf:params:xml:ns:carddav)
[debug] Received <response> for https://sogo.myserver.com/SOGo/dav/fred@bloggsfamily.id/Contacts/personal/5281-5657B880-1-2C1A198.vcf, status: null, properties: [address-data(urn:ietf:params:xml:ns:carddav): AddressData(vCard=BEGIN:VCARD
UID:5281-5657B880-1-2C1A198.vcf
VERSION:3.0
CLASS:PUBLIC
PROFILE:VCARD
N:;Joe Bloggs
FN:Joe Bloggs
EMAIL;TYPE=work:joeblogs@example.com
END:VCARD),
getetag(DAV:): GetETag(eTag=gcs00000000)]
[debug] Found remote VCard: 5281-5657B880-1-2C1A198.vcf
[info ] Comparing local/remote entries
[info ] 530C-5657B900-1-2A2FE6C0.vcf is not on server anymore, deleting
[info ] Downloading remote entries
[info ] Downloading 0 contacts (10 at once)
[info ] Saving sync state
[info ] Saving CTag=1448591266
    0
  • rfc2822
    developer

    1. There are multiple <C:address-data> elements in the same response, which doesn’t make any sense. Can you please report this problem to SOGo?
    2. It’s a known SOGo problem that contacts without email address are/were not listed in the response. As far as I know, this has already been fixed.
    0
  • S

    1. There are multiple <C:address-data> elements in the same response, which doesn’t make any sense. Can you please report this problem to SOGo?

    Okay I’ll do that. Filed at SOGo #3400

    Summary: Multiple <C:address-data> elements are issued in the same response.
    Description: paste of above input data and output trace

    I don’t really know much about cardav/caldav. 🙂

    1. It’s a known SOGo problem that contacts without email address are/were not listed in the response. As far as I know, this has already been fixed.

    Well I’m running the latest SOGo 2.3.3a on CentOS, and it certainly still happens. That bug is still set to status new, maybe the change never got merged into 2.3.3?

    0 rfc2822 1 Reply
  • rfc2822
    developer

    @sillysausage said:

    That bug is still set to status new, maybe the change never got merged into 2.3.3?

    Perfectly possible. Maybe you can ask in that SOGo bug report?

    0
  • K

    The missing entries issue hasn’t been fixed upstream yet. I’ve applied the change as mentioned in SOGo #3373 which fixes the issue, but I am still seeing the duplicate returns as now raised in SOGo #3400.

    However, I think the “duplicate” entries is intentional, as there is a comment in the source code about compatibility; ‘address-data’ vs. ‘addressbook-data’. This doesn’t seem to have any adverse affects in DAVdroid.

    0 rfc2822 1 Reply
  • rfc2822
    developer

    @kwirk said:

    However, I think the “duplicate” entries is intentional, as there is a comment in the source code about compatibility; ‘address-data’ vs. ‘addressbook-data’. This doesn’t seem to have any adverse affects in DAVdroid.

    You’re right, I have read two times “addressbook-data” by mistake. However, I haven’t seen such a solution yet and it seems quite a waste of bandwidth? But you’re right, DAVdroid of course ignores unknown DAV properties.

    0
  • J

    This seems to have been fixed in SOGo 2.3.7.

    0
solved 466 3rd-party issue 290 sogo 9
Log in to reply
 

Similar topics