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

lyallp · 2020-10-14T04:28:33Z

Steps to reproduce

create contact with multiple email addresses and/or ADR addresses
export contact
delete contact and refresh page, to be sure
edit vcard according to https://tools.ietf.org/html/rfc6350
import edited vcard
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:[email protected]
EMAIL;PREF=10,TYPE=OTHER:[email protected]
EMAIL;PREF=15,TYPE=OTHER:[email protected]
EMAIL;PREF=20,TYPE=OTHER:[email protected]
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":[email protected]
EMAIL;PREF="10,TYPE=OTHER":[email protected]
EMAIL;PREF="15,TYPE=OTHER":[email protected]
EMAIL;PREF="20,TYPE=OTHER":[email protected]
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) ...

The text was updated successfully, but these errors were encountered:

lyallp · 2020-10-14T04:53:50Z

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 · 2020-10-14T05:16:50Z

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: nextcloud/server#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:[email protected]
EMAIL;PREF=10,TYPE=OTHER:[email protected]
EMAIL;PREF=15,TYPE=OTHER:[email protected]
EMAIL;PREF=20,TYPE=OTHER:[email protected]
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:[email protected]
EMAIL:[email protected]
EMAIL:[email protected]
EMAIL:[email protected]
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:[email protected]
EMAIL;TYPE=OTHER,PREF=1:[email protected]
EMAIL;TYPE=OTHER,PREF=15:[email protected]
EMAIL;TYPE=OTHER,PREF=20:[email protected]
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:[email protected]
EMAIL;TYPE="OTHER,PREF=1":[email protected]
EMAIL;TYPE="OTHER,PREF=15":[email protected]
EMAIL;TYPE="OTHER,PREF=20":[email protected]
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 · 2020-10-14T05:32:10Z

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 · 2020-10-14T06:01:08Z

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 · 2020-10-14T06:36:35Z

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:[email protected]
EMAIL;TYPE=PREF;TYPE=OTHER:[email protected]
EMAIL;TYPE=PREF;TYPE=OTHER:[email protected]

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

EMAIL;PREF=1;TYPE=HOME:[email protected]
EMAIL;PREF=10;TYPE=OTHER:[email protected]
EMAIL;PREF=15;TYPE=OTHER:[email protected]

So, exporting from Contacts seems good, CardBook not. I will trawl through my entire contacts vCard entries and fix the PREF/TYPE entries 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 · 2020-10-14T06:46:36Z

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 · 2020-10-14T07:04:21Z

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 ITEM entries 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 · 2020-10-14T07:23:59Z

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 🤔

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

lyallp · 2020-10-14T07:46:51Z

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 · 2020-10-14T08:16:04Z

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

lyallp · 2020-10-14T08:26:25Z

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 · 2020-10-14T08:28:05Z

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 · 2020-10-14T08:36:46Z

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 · 2020-10-14T08:49:12Z

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 · 2020-10-14T11:20:41Z

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 · 2020-10-14T11:22:28Z

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

#4038

skjnldsv · 2020-10-14T11:22:54Z

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

see nextcloud/server#631

lyallp · 2020-10-14T11:25:10Z

My apologies if I have been stating the obvious.

skjnldsv · 2020-10-14T11:32:23Z

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

So the issue here is only about the downloaded vcard?
Because other than the download issue (#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 · 2020-10-14T11:44:27Z

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 · 2020-10-14T13:10:12Z

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 · 2020-10-14T13:31:50Z

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 · 2020-10-15T01:23:48Z

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.

lyallp added 0. to triage Pending approval or rejection. This issue is pending approval. bug Something isn't working labels Oct 14, 2020

lyallp changed the title ~~Card corrupts contact between import and export of same contact~~ Contacts corrupts contact between import and export of same contact Oct 14, 2020

joshtrichards added the feature: import Importing (and exporting) label Jun 15, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

lyallp commented Oct 14, 2020

lyallp commented Oct 14, 2020

call-me-matt commented Oct 14, 2020 •

edited

Loading

lyallp commented Oct 14, 2020 •

edited

Loading

call-me-matt commented Oct 14, 2020 •

edited

Loading

lyallp commented Oct 14, 2020

call-me-matt commented Oct 14, 2020 •

edited

Loading

lyallp commented Oct 14, 2020

skjnldsv commented Oct 14, 2020

lyallp commented Oct 14, 2020

skjnldsv commented Oct 14, 2020

lyallp commented Oct 14, 2020

call-me-matt commented Oct 14, 2020 •

edited

Loading

skjnldsv commented Oct 14, 2020

lyallp commented Oct 14, 2020

lyallp commented Oct 14, 2020

skjnldsv commented Oct 14, 2020

skjnldsv commented Oct 14, 2020

lyallp commented Oct 14, 2020

skjnldsv commented Oct 14, 2020

lyallp commented Oct 14, 2020

lyallp commented Oct 14, 2020

lyallp commented Oct 14, 2020

lyallp commented Oct 15, 2020

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

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

Comments

lyallp commented Oct 14, 2020

Steps to reproduce

Expected behaviour

Actual behaviour

Server configuration detail

Client configuration

Logs

lyallp commented Oct 14, 2020

call-me-matt commented Oct 14, 2020 • edited Loading

lyallp commented Oct 14, 2020 • edited Loading

call-me-matt commented Oct 14, 2020 • edited Loading

lyallp commented Oct 14, 2020

call-me-matt commented Oct 14, 2020 • edited Loading

lyallp commented Oct 14, 2020

skjnldsv commented Oct 14, 2020

lyallp commented Oct 14, 2020

skjnldsv commented Oct 14, 2020

lyallp commented Oct 14, 2020

call-me-matt commented Oct 14, 2020 • edited Loading

skjnldsv commented Oct 14, 2020

lyallp commented Oct 14, 2020

lyallp commented Oct 14, 2020

skjnldsv commented Oct 14, 2020

skjnldsv commented Oct 14, 2020

lyallp commented Oct 14, 2020

skjnldsv commented Oct 14, 2020

lyallp commented Oct 14, 2020

lyallp commented Oct 14, 2020

lyallp commented Oct 14, 2020

lyallp commented Oct 15, 2020

call-me-matt commented Oct 14, 2020 •

edited

Loading

lyallp commented Oct 14, 2020 •

edited

Loading

call-me-matt commented Oct 14, 2020 •

edited

Loading

call-me-matt commented Oct 14, 2020 •

edited

Loading

call-me-matt commented Oct 14, 2020 •

edited

Loading