search

nextcloud / contacts

📇 Contacts app for Nextcloud
https://apps.nextcloud.com/apps/contacts
GNU Affero General Public License v3.0
570 stars 173 forks source link

Contacts corrupts contact between import and export of same contact #1850

Open lyallp opened 4 years ago

lyallp commented 4 years ago

Steps to reproduce

  1. create contact with multiple email addresses and/or ADR addresses
  2. export contact
  3. delete contact and refresh page, to be sure
  4. edit vcard according to https://tools.ietf.org/html/rfc6350
  5. import edited vcard
  6. export contact to new vcard file vcard file corrupted

Expected behaviour

vcard format according to RFC - PREF=1..100, not text. Whole meaning of PREF is lost as it is soaked up by text string. Additionally, expect TYPE=Bogus to show in web UI as Bogus, but Bogus is lost somewhere, leaving the web UI with defaults.

Actual behaviour

EMAIL;PREF=1,TYPE=HOME:xxxxx@xxxxxxxxxxx.com
EMAIL;PREF=10,TYPE=OTHER:xxxxxxxxxxxx@xxxxx.com
EMAIL;PREF=15,TYPE=OTHER:xxxxxxx@xxxxxxxxxxxxxxxx.com
EMAIL;PREF=20,TYPE=OTHER:xxxxxxx@xxxxxxxxxxxxxxxx.info
TEL;PREF=1,TYPE=CELL:+61 ### ### ###
ADR;PREF=1,TYPE=HOME:;;xx xxxxxx xx;xxxxxxxxx;xxxxxxxxxxxxxxx;xxxx;Australi
 a
ADR;PREF=10,TYPE=OTHER:;;xxxxxxxxxxxxxxxxxxxxxxxx;xxxxxx;xxxxxxxxxxxxxxx;2
 034;Australia

converts to 

EMAIL;PREF="1,TYPE=HOME":xxxxx@xxxxxxxxxxx.com
EMAIL;PREF="10,TYPE=OTHER":xxxxxxxxxxxx@xxxxx.com
EMAIL;PREF="15,TYPE=OTHER":xxxxxxx@xxxxxxxxxxxxxxxx.com
EMAIL;PREF="20,TYPE=OTHER":xxxxxxx@xxxxxxxxxxxxxxxx.info
TEL;PREF="1,TYPE=CELL";VALUE=UNKNOWN:+61 ### ### ###
ADR;PREF="1,TYPE=HOME":;;xxxxxxxxxxxx;xxxxxxxxx;xxxxxxxxxxxxxxx;xxxx;Austra
 lia
ADR;PREF="10,TYPE=OTHER":;;xxxxxxxxxxxxxxxxxxxxxxxx;xxxxxx;xxxxxxxxxxxxxxx;
 2034;Australia

Server configuration detail

Operating system: Linux 2.6.32-954.3.5.lve1.4.78.el6.x86_64 nextcloud/server#1 SMP Thu Mar 26 08:20:27 EDT 2020 x86_64

Webserver: LiteSpeed (litespeed)

Database: mysql 5.6.49

PHP version:

7.4.11 Modules loaded: Core, date, libxml, openssl, pcre, sqlite3, zlib, bz2, calendar, ctype, curl, hash, filter, ftp, gettext, gmp, SPL, iconv, pcntl, readline, Reflection, session, standard, shmop, SimpleXML, mbstring, tokenizer, xml, litespeed, bcmath, dom, fileinfo, gd, imagick, imap, intl, json, exif, mysqli, mysqlnd, PDO, pdo_mysql, pdo_sqlite, Phar, posix, soap, sockets, timezonedb, xmlreader, xmlrpc, xmlwriter, xsl, zip, Zend OPcache

Nextcloud version: 20.0.0 - 20.0.0.9

Updated from an older Nextcloud/ownCloud or fresh install: updated

Where did you install Nextcloud from: unknown

Signing status Array ( )
List of activated apps ``` Enabled: - accessibility: 1.6.0 - activity: 2.13.1 - admin_audit: 1.10.0 - apporder: 0.11.0 - bookmarks: 3.4.3 - calendar: 2.1.2 - camerarawpreviews: 0.7.8 - cloud_federation_api: 1.3.0 - comments: 1.10.0 - contacts: 3.4.0 - contactsinteraction: 1.1.0 - dashboard: 7.0.0 - dav: 1.16.0 - extract: 1.2.4 - federatedfilesharing: 1.10.1 - files: 1.15.0 - files_markdown: 2.3.1 - files_pdfviewer: 2.0.1 - files_rightclick: 0.17.0 - files_sharing: 1.12.0 - files_videoplayer: 1.9.0 - firstrunwizard: 2.9.0 - issuetemplate: 0.7.0 - keeweb: 0.6.3 - logreader: 2.5.0 - lookup_server_connector: 1.8.0 - notes: 4.0.0 - notifications: 2.8.0 - oauth2: 1.8.0 - password_policy: 1.10.1 - photos: 1.2.0 - privacy: 1.4.0 - provisioning_api: 1.10.0 - recommendations: 0.8.0 - serverinfo: 1.10.0 - settings: 1.2.0 - sharebymail: 1.10.0 - support: 1.3.0 - survey_client: 1.8.0 - systemtags: 1.10.0 - tasks: 0.13.4 - text: 3.1.0 - theming: 1.11.0 - twofactor_backupcodes: 1.9.0 - updatenotification: 1.10.0 - user_status: 1.0.0 - viewer: 1.4.0 - weather_status: 1.0.0 - workflowengine: 2.2.0 Disabled: - encryption - federation - files_external - files_trashbin - files_versions - nextcloud_announcements - user_ldap ```
Configuration (config/config.php) ``` { "installed": true, "dbtype": "mysql", "dbname": "***REMOVED SENSITIVE VALUE***", "dbuser": "***REMOVED SENSITIVE VALUE***", "dbpassword": "***REMOVED SENSITIVE VALUE***", "dbhost": "***REMOVED SENSITIVE VALUE***", "dbtableprefix": "oc_", "forcessl": false, "theme": "", "3rdpartyroot": "", "3rdpartyurl": "", "blacklisted_files": [ ".htaccess" ], "default_language": "en", "default_locale": "en_AU", "overwritehost": "", "overwriteprotocol": "https", "overwritewebroot": "", "overwritecondaddr": "", "overwrite.cli.url": "https:\/\/cloud.remotely-helpful.com\/", "htaccess.RewriteBase": "\/", "defaultapp": "dashboard", "knowledgebaseenabled": true, "knowledgebaseurl": "http:\/\/api.apps.nextcloud.com\/v1", "appstoreenabled": true, "appstoreurl": "https:\/\/apps.nextcloud.com\/api\/v1", "apps_paths": [ { "path": "\/home\/remotely\/www\/cloud\/apps", "url": "\/apps", "writable": true } ], "mail_smtpdebug": false, "mail_smtpmode": "smtp", "mail_smtphost": "***REMOVED SENSITIVE VALUE***", "mail_smtpport": "587", "mail_smtptimeout": 10, "mail_smtpauthtype": "LOGIN", "appcodechecker": true, "log_type": "nextcloud", "logfile": "\/home\/remotely\/cloud\/logs\/nextcloud.log", "loglevel": 2, "logdateformat": "F d, Y H:i:s", "logtimezone": "Australia\/Sydney", "log_rotate_size": 104857600, "passwordsalt": "***REMOVED SENSITIVE VALUE***", "hashingCost": 10, "trashbin_retention_obligation": "180, auto", "allow_user_to_change_display_name": true, "xframe_restriction": true, "custom_csp_policy": "default-src 'self'; script-src 'self' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; frame-src *; img-src *; font-src 'self' data:; media-src *", "customclient_desktop": "", "customclient_android": "", "customclient_ios": "", "remember_login_cookie_lifetime": 1296000, "session_keepalive": true, "updatechecker": true, "updater.server.url": "https:\/\/updates.nextcloud.com\/updater_server\/", "updater.release.channel": "stable", "has_internet_connection": true, "writable_appsdir": true, "datadirectory": "***REMOVED SENSITIVE VALUE***", "version": "20.0.0.9", "maxZipInputSize": "838860800", "allowZipDownload": true, "instanceid": "***REMOVED SENSITIVE VALUE***", "maintenance": false, "trusted_domains": [ "cloud.remotely-helpful.info", "cloud.remotely-helpful.com", "remotely-helpful.info", "remotely-helpful.com", "remotelyhelpful.info", "remotelyhelpful.com", "remotelyhelpful.info.au", "remotelyhelpful.com.au", "remotely-helpful.info.au", "remotely-helpful.com.au", "vmres08.auserver.com.au" ], "secret": "***REMOVED SENSITIVE VALUE***", "mail_from_address": "***REMOVED SENSITIVE VALUE***", "mail_domain": "***REMOVED SENSITIVE VALUE***", "appstore.experimental.enabled": true, "mail_smtpauth": 1, "mail_smtpname": "***REMOVED SENSITIVE VALUE***", "mail_smtppassword": "***REMOVED SENSITIVE VALUE***", "app_install_overwrite": [ "keeweb", "apporder", "calendar", "contacts", "external", "camerarawpreviews", "tasks", "bookmarks", "occweb", "extract" ], "mysql.utf8mb4": false, "enabledPreviewProviders": [ "OC\\Preview\\PNG", "OC\\Preview\\JPEG", "OC\\Preview\\GIF", "OC\\Preview\\HEIC", "OC\\Preview\\BMP", "OC\\Preview\\XBitmap", "OC\\Preview\\MP3", "OC\\Preview\\TXT", "OC\\Preview\\MarkDown", "OC\\Preview\\OpenDocument", "OC\\Preview\\Krita" ], "tempdirectory": "\/home\/remotely\/tmp\/NextCloud" } ```

Are you using external storage, if yes which one: local/smb/sftp/...

Are you using encryption:

Are you using an external user-backend, if yes which one: LDAP/ActiveDirectory/Webdav/...

Client configuration

Browser: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.75 Safari/537.36

Operating system:

Logs

Web server error log ``` Insert your web server log here ```
Nextcloud log ``` Insert your Nextcloud log here ```
Browser log Insert your browser log here, this could for example include: a) The javascript console log b) The network log c) ...
lyallp commented 4 years ago

Same applies to RELATED, parameters are soaked up into TYPE. Possibly a generic problem with TYPE interpretation? I suspect this is related to issue nextcloud/server#1845

from

RELATED;TYPE=parent,VALUE=text:aaaaaaaaa
RELATED;TYPE=brother,VALUE=text:bbbbbbbbb
RELATED;TYPE=sister,VALUE=text:ccccccccc

to

RELATED;TYPE="parent,VALUE=text";VALUE=UNKNOWN:aaaaaaaaa
RELATED;TYPE="brother,VALUE=text";VALUE=UNKNOWN:bbbbbbbbb
RELATED;TYPE="sister,VALUE=text";VALUE=UNKNOWN:ccccccccc
call-me-matt commented 4 years ago

I cannot reproduce it exactly like that.

When I import your vCard I am "only" losing some TYPEs, no values. And exporting again, the PREFs are gone, as Nextcloud Contacts does not support that (yet).

It might be related to an issue I fixed on server lately and that will come with the next update: https://github.com/nextcloud/server/issues/20544

Here is how it looks for me:

generated contact for import ``` BEGIN:VCARD VERSION:4.0 FN:Mr Test EMAIL;PREF=1,TYPE=HOME:xxxxx@xxxxxxxxxxx.com EMAIL;PREF=10,TYPE=OTHER:xxxxxxxxxxxx@xxxxx.com EMAIL;PREF=15,TYPE=OTHER:xxxxxxx@xxxxxxxxxxxxxxxx.com EMAIL;PREF=20,TYPE=OTHER:xxxxxxx@xxxxxxxxxxxxxxxx.info TEL;PREF=1,TYPE=CELL:+61 ### ### ### ADR;PREF=1,TYPE=HOME:;;xx xxxxxx xx;xxxxxxxxx;xxxxxxxxxxxxxxx;xxxx;Australi a ADR;PREF=10,TYPE=OTHER:;;xxxxxxxxxxxxxxxxxxxxxxxx;xxxxxx;xxxxxxxxxxxxxxx;2 034;Australia RELATED;TYPE=parent,VALUE=text:aaaaaaaaa RELATED;TYPE=brother,VALUE=text:bbbbbbbbb RELATED;TYPE=sister,VALUE=text:ccccccccc END:VCARD ```
exported from Nextcloud ``` BEGIN:VCARD VERSION:3.0 PRODID:-//Sabre//Sabre VObject 4.3.0//EN FN:Mr Test EMAIL:xxxxx@xxxxxxxxxxx.com EMAIL:xxxxxxxxxxxx@xxxxx.com EMAIL:xxxxxxx@xxxxxxxxxxxxxxxx.com EMAIL:xxxxxxx@xxxxxxxxxxxxxxxx.info TEL:+61 ### ### ### ADR:;;xx xxxxxx xx;xxxxxxxxx;xxxxxxxxxxxxxxx;xxxx;Australia ADR:;;xxxxxxxxxxxxxxxxxxxxxxxx;xxxxxx;xxxxxxxxxxxxxxx;2034;Australia RELATED;TYPE="parent,VALUE=text":aaaaaaaaa RELATED;TYPE="brother,VALUE=text":bbbbbbbbb RELATED;TYPE="sister,VALUE=text":ccccccccc UID:060cbba4-4a6e-4740-b7a0-5b060441923a REV;VALUE=DATE-TIME:20201014T051949Z END:VCARD ```

EDIT: I found out the order is important. See below, after moving PREF behind TYPE:

generated contact for import ``` BEGIN:VCARD VERSION:4.0 FN:Mr Test EMAIL;TYPE=HOME:xxxxx@xxxxxxxxxxx.com EMAIL;TYPE=OTHER,PREF=1:xxxxxxxxxxxx@xxxxx.com EMAIL;TYPE=OTHER,PREF=15:xxxxxxx@xxxxxxxxxxxxxxxx.com EMAIL;TYPE=OTHER,PREF=20:xxxxxxx@xxxxxxxxxxxxxxxx.info TEL;TYPE=CELL,PREF=1:+61 ### ### ### ADR;TYPE=HOME,PREF=1:;;xx xxxxxx xx;xxxxxxxxx;xxxxxxxxxxxxxxx;xxxx;Australi a ADR;PREF=10,TYPE=OTHER:;;xxxxxxxxxxxxxxxxxxxxxxxx;xxxxxx;xxxxxxxxxxxxxxx;2 034;Australia RELATED;TYPE=parent,VALUE=text:aaaaaaaaa RELATED;TYPE=brother,VALUE=text:bbbbbbbbb RELATED;TYPE=sister,VALUE=text:ccccccccc END:VCARD ```
exported from Nextcloud ``` BEGIN:VCARD VERSION:3.0 PRODID:-//Sabre//Sabre VObject 4.3.0//EN FN:Mr Test EMAIL;TYPE=HOME:xxxxx@xxxxxxxxxxx.com EMAIL;TYPE="OTHER,PREF=1":xxxxxxxxxxxx@xxxxx.com EMAIL;TYPE="OTHER,PREF=15":xxxxxxx@xxxxxxxxxxxxxxxx.com EMAIL;TYPE="OTHER,PREF=20":xxxxxxx@xxxxxxxxxxxxxxxx.info TEL;TYPE="CELL,PREF=1":+61 ### ### ### ADR;TYPE="HOME,PREF=1":;;xx xxxxxx xx;xxxxxxxxx;xxxxxxxxxxxxxxx;xxxx;Austra lia ADR:;;xxxxxxxxxxxxxxxxxxxxxxxx;xxxxxx;xxxxxxxxxxxxxxx;2034;Australia RELATED;TYPE="parent,VALUE=text":aaaaaaaaa RELATED;TYPE="brother,VALUE=text":bbbbbbbbb RELATED;TYPE="sister,VALUE=text":ccccccccc UID:32b920cf-afe3-4923-9357-87269f2a1132 REV;VALUE=DATE-TIME:20201014T053133Z END:VCARD ```
lyallp commented 4 years ago

Interesting that PREF causes loss of TYPE but TYPE soaks up everything behind it into a useless value that is lost/discarded down the track, by clients that sync and discard the TYPE value, then sync back the contact minus the TYPE. Or something like that. :)

Is it possible to stop syncing of contacts with external clients, such as Thunderbird+CardBook and iPhones, so tests can be done in isolation?

CardBook add-on for Thunderbird isn't exactly perfect either and iPhones are notorious for using ITEM entries.

I am happy to participate in testing and validation against the RFC, if there is a framework that tests contacts in isolation.

Unfortunately all I have is Win10 at the moment, my linux machine wont be available to me till November (Stuck in Sydney, live in Adelaide).

My NextCloud instance is hosted on a shared linux server and I actively use it, so am somewhat hesitant to 'break' it.

...Lyall

call-me-matt commented 4 years ago

In your linked RFC the PREF is separated with a ;, not with a ,. If I modify the imported vCard this way, things look much better here (everything is kept, also PREF. Only the PREF integer value is lost, maybe that's not part of vCard v3.0 to which it is exported to?)

Considering debug: can't you just deactivate the account on your phone and quit Thunderbird? Otherwise I can only help with linux.

lyallp commented 4 years ago

In your linked RFC the PREF is separated with a ;, not with a ,.

Good call! Using a ; produces a much better result. On the iPhone, things are looking good. Now I don't know if it's contacts or the Thunderbird add-on CardBook addon, because if I look at a contacts vCard in CardBook, I see

EMAIL;TYPE=PREF;TYPE=HOME:zzzzzzz@zzzzz.com
EMAIL;TYPE=PREF;TYPE=OTHER:yyyyy@yyyyy.com
EMAIL;TYPE=PREF;TYPE=OTHER:xxxx@xxxxxxx.com

when I expected to see (having lost the preferred order, as dictated by the PREFvalues.)

EMAIL;PREF=1;TYPE=HOME:zzzzzzz@zzzzz.com
EMAIL;PREF=10;TYPE=OTHER:yyyyy@yyyyy.com
EMAIL;PREF=15;TYPE=OTHER:xxxx@xxxxxxx.com

So, exporting from Contacts seems good, CardBook not. I will trawl through my entire contacts vCard entries and fix the PREF/TYPEentries but I suspect CardBook sync is causing issues. I will close this issue if I can definitely nail CardBook as the culprit in the above 'issue'.

call-me-matt commented 4 years ago

I think both variants (PREF as TYPE and PREF alone) are valid. Maybe in different vCard versions, though. Only the comma-separated individual PREF is not. But when there is no integer value and all entries are preferred, that does not help, of course.

lyallp commented 4 years ago

PREF defaults to value 1, if no value supplied. Really beginning to suspect CardBook as post CardBook edit (with nothing changed) PREF=10;TYPE=OTHER became TYPE=PREF;TYPE=OTHER in addition to the second postal address changing from ADR;PREF=10;TYPE=OTHER: to ITEM1.ADR;TYPE=PREF:..... ITEM1.X-ABLABEL:OTHER Exporting a contact using CardBook shows the above conversion. So it's either CardBook itself or the Sync between Contacts and CardBook.

The use of ITEMentries is something the iPhone used to do, many moons ago. Maybe CardBook is using an old library. Anyway, I will chase this up via CardBook, feel free to close this issue if you wish, although I am happy to report back with my findings.

Regarding testing, come November 2020, feel free to contact me regarding testing, as I will have access to my linux by then 👍

skjnldsv commented 4 years ago

Yes, something weird is going on. What should happen and be valid

TEL;VALUE=uri;PREF=1;TYPE="voice,home":tel:+1-555-555-5555;ext=5555
TEL;TYPE=VOICE,HOME:tel:+1-555-555-5555;ext=5555
TEL;TYPE=VOICE;TYPE=HOME:tel:+1-555-555-5555;ext=5555
TEL;VALUE=uri;TYPE=home:tel:+33-01-23-45-67

There is an opened issue about the quotes around TYPE="voice,home" that iOS/macOs doesn't supports, but that is another story and this is still valid :thinking:

@lyallp your vcards are have the 4.0 VERSION field, right?

lyallp commented 4 years ago

All references in my post are for vCard 3.0 as per RFC 6350
Basically PREF is an ordering field and has nothing to do with TYPE. TYPE can still have a value of PREF and be interpreted as the equivalent of PREF=1 or PREF (which defaults to 1) by the client but if you have multiple EMAILs, for example, you will lose the order defined by PREF=# if you convert to TYPE=PREF.

skjnldsv commented 4 years ago

Rfc rfc6350 is vcard 4 :) Rfc 2426 https://tools.ietf.org/html/rfc2426#section-3.6.9 is 3.0!

lyallp commented 4 years ago

Whoops, you are entirely correct, so..., Contacts exports contact vcf files with vCard 4 entries yet labels the file with a VERSION:3.0

call-me-matt commented 4 years ago

you will lose the order defined by PREF=# if you convert to TYPE=PREF.

Well, my phone lets me chose exactly one PREF per field, which will then be pre-selected when I want to contact that person. So it does make sense to keep the PREF without numbers, but only for one of them.

skjnldsv commented 4 years ago

So, Nextcloud contacts doesn't support pref yet (#202) I'm confused about the breakage of vcards.

Our lib knows the diff between vcard3 and vcard4. Could you post the vcard before Nextcloud touches it and after? Did you create the card from Nextcloud? From an external client?

lyallp commented 4 years ago

I exported a contact from NextCloud Contacts and tweaked entries manually. I then deleted that contact from NextCloud then imported the file I Manually tweaked, with the incorrect VERSION as I subsequently found out (3.0 with entries containing PREF), technically invalid. NextCloud Contacts happily accepted my file. iPhones seem to be ok with them too. My current suspicion is Thunderbird Addon CardBook is (correctly) discarding vCard 4.0 fields in the 3.0 vCards on sync. I am in discussions with CardBook developers. Its painful trying to figure out who is right, including me!

lyallp commented 4 years ago

I found that if I import a v4 vCard into NextCloud contacts, refresh and immediately download the contact, the download is converted to v3 vCard including removal of PREF fields and altering the PHOTO to version 3.0 format.

Additionally, when synced to Thunderbird Cardbook, the vCard is 3.0, thus losing PREF entries, even though CardBook supposedly accepts v4.0 vCards. I won't mention that Contacts is generating v3.0 vCards with v4.0 fields, such as RELATED. :)

Thus, whilst Contacts accepts v4.0, it seems to convert to v3.0 in most fields.

skjnldsv commented 4 years ago

the download is converted to v3 vCard including removal of PREF fields and altering the PHOTO to version 3.0 format.

https://github.com/nextcloud/contacts/issues/4038

skjnldsv commented 4 years ago

I won't mention that Contacts is generating v3.0 vCards with v4.0 fields, such as RELATED.

see nextcloud/server#631

lyallp commented 4 years ago

My apologies if I have been stating the obvious.

skjnldsv commented 4 years ago

Well, not really "obvious", you have to find those issues ^^ Not an easy task sometimes, I'm often lost myself! :wink:

So the issue here is only about the downloaded vcard? Because other than the download issue (nextcloud/contacts#4038), any syncing will still serve the original vcard, the vcard is converted in v3.0 on download but we of course don't alter the card in our database :)

lyallp commented 4 years ago

The last issue seems to be the conversion to v3.0 on download. A separate issue, as long as Contact syncs out v4.0, needs to be raised with CardBook, it seems to convert from 4.0 to 3.0 on sync. Should I edit the vCard in CardBook, the converted vCard in CardBook is synced back to Contacts, converting the internal vCard within Contacts to v3.0. I am unsure if the conversion from 4.0 to 3.0 in CardBook triggers sync back to Contacts, or sync only occurs if I edit a one or more fields in CardBook. Does all this sound feasible?

lyallp commented 4 years ago

This is all very complicated. I am unsure where problems exists, Contacts, CardBook or even iPhone Contacts.

My CardBook Address book is vCard 3.0.

I have re-created my CardBook AddressBook as v4.0

Sync from NextCloud seems mostly ok, except all PREF fields are set to 1.

Once iPhone gets hold of the contact, via NextCloud sync, all things go to hell in a hand basket with emails and addresses converted to ITEM# entries, which royally screws the display of the contact in NextCloud Contacts.

I recreated the CardBook AddressBook as v3.0, iPhone still screws the vCard, but still, CardBook deals with the altered vCard better than NextCloud Contacts, which does not display the ITEM# fields 🙁

I am starting to regret diving down this rabbit hole!

I will continue to fiddle, and report back.

lyallp commented 4 years ago

I checked the NextCloud database, oc_cards and oc_cards_properties seem to be exactly as you and I suspected, blob is v4.0 and properties correspond to the vCard. I am starting to feel like a Gooney bird, flying in smaller and smaller circles until it disappears up it’s own a***ole.

lyallp commented 4 years ago

I use NextCloud, Contacts App, synced to both iPhone and email client Thunderbird CardBook addon.

They all fight each other during sync.

Ok, NextCloud Contacts will load and store vCard 4.0.

CardBook add-on syncs, throws away stuff like PREF=<anything other than 1>

iPhone converts many fields to ITEM#

CardBook does a reasoable job of displaying all the fields resulting from the iPhone mash up, except RELATED

NextCloud Contacts, whilst having all the info in the knackered vCard from the iPhone, does not display any ITEM# fields. Things like a second ADR whilst converted to an ITEM#, by the iPhone sync, are no longer displayed, same with RELATED and ALL Email entries.

The iPhone seems to do a good job after it has knackered the vCard. Next comes CardBook addon, does a reasonable job of dealing with the iPhone generated vCard. Last is NextCloud Contacts, which successfully stores the vCard, is the worst at coping with the fields and displaying them.

It appears I must choose a platform as my 'reference' and ignore the other two.

I dont use any web based services because I cannot guarantee they will be there tomorrow or that they wont charge for service, take Google Reader as an example.

sigh... this issue is a combination of 3.