Remove quotes from TYPE for better external platforms compatibility

[ghost]

This is a resubmit as I ended up doing more investigation following a switch to using Google Contacts due to this problem - during the switch, I had to manually edit the VCF file to get it to work with Gmail.

The VCF file produced by Contacts doesn't use fields recognised by other applications and appears to be non-standard. As it currently stands, it appears Contacts is incompatible with all other major platforms.

Nextcloud 16.0.1, Contacts 3.1.1

Example:

1. New contact created in the web app, with a phone number and email. The type (e.g. home, office) is left on the defaults.
   

2. The contact is downloaded through the web app (.VCF file).

3. The file is opened in Outlook, revealing a missing phone number.
   

4. The file is imported to gmail, again revealing a missing phone number.
   
   

5. Sync to iOS also reveals a missing phone number.
   

6. Opening the VCF in ATOM reveals the field names. You can see email has the type HOME but phone has (quotes included as in the file) "HOME,VOICE".
   

7. Removing ,VOICE and the quotation marks to leave the type as HOME results in Gmail and Outlook now seeing the phone number.
   

[skjnldsv]

Right, we should remove the quotations for compatibility. :)

Thanks for reporting!

[giddyhup]

This is also happening with the popular productivity/email program eM Client.

[giddyhup]

If I read it correctly, there were fixes to kewisch/ical.js#343 but that issue hasn't been closed yet. Is there hope that the fixes find their way to Nextcloud Contacts?

[skjnldsv]

@giddyhup Maybe, but we really need kewisch/ical.js#343

[giddyhup]

ACK. Understood.

[giddyhup]

I looked into the topic again and would like to share my observations. According to RFC 6350 section 6.4.1 both ways to represent phone number types are okay:

The default type is "voice". These type parameter values can be specified as a parameter list (e.g., TYPE=text;TYPE=voice) or as a value list (e.g., TYPE="text,voice").

In my tests my clients support parameter lists and have problems with value lists. The issue occurs since the Contacts app changes the parameter representation. Also, something like TEL;type=CELL;type=VOICE;type=pref: 555 1234 appears as undefined phone number in the web interface. When there are modifications to the address via the web interface in the synced VCard we only find TEL;TYPE=pref:555 1234.

[skjnldsv]

Yes, because the library we're using does not understand multiple parameters

[giddyhup]

Sorry, I now have the whole picture. I just went down the rabbit hole and and also found the pull request from April 5 which probably would fix it. : (

[giddyhup]

The pull request has been merged! Yay!

[ghost]

@giddyhup Do you know when it will be released?

[giddyhup]

@a1pilot nope. One needs to watch the respective repository. The last release was in 2018 and the one before that was in 2016. Then it is up to the Nextcloud/contacts maintainers to include it in their release. I assume that together can take some months.

[Timokirch]

Hey, there was a new release :) That‘s the best easter present this year.

[giddyhup]

In this repository, package.json references ical.js v1.4 (Mozzilla's recently released version with the fix). Does this mean version 3.2.0 of the Nextcloud contacts already includes the fix? Can we close the issue?

[Timokirch]

For me there are still errors if i modify a contact on an ios device and looking at the object over the web browser.

[skjnldsv]

In this repository, package.json references ical.js v1.4 (Mozzilla's recently released version with the fix). Does this mean version 3.2.0 of the Nextcloud contacts already includes the fix? Can we close the issue?

no it means I need to release a new version :)
Would you be willing to test it here?

[skjnldsv]

Please help test the new release (link in first post): #1579

[giddyhup]

Is there a testing procedure? Can the respective existing app folder simply renamed and the new folder put in its place instead?

[skjnldsv]

You can replace the app with this archive. If anything happens, delete it and reinstall contacts through the appstore as usual :)

[giddyhup]

Ok, I am testing. I can't tell if it is related to this release and to this issue but here it goes (just tell me if I should open a new issue).

One contact renders my Windows client (EM client) unresponsive when I try to add the downloaded vcf file manually (it won't get synced automatically).

An address appears in the web form in one field, in the vcf it appears like this:
item2.ADR;type=HOME;type=pref:;;STREET;TOWN;;ZIP;COUNTRY
Phone number entries appear like this:
TEL;TYPE="HOME,VOICE";VALUE=UNKNOWN:+1 555 1234567

Again, I don't know if this is related to the fix. Also, the entries have also been edited under iOS and the changes may come from there.

[skjnldsv]

item2.ADR;type=HOME;type=pref:;;STREET;TOWN;;ZIP;COUNTRY

We don't support type pref, so it's not coming from nextcloud here. :/

Phone number entries appear like this:
TEL;TYPE="HOME,VOICE";VALUE=UNKNOWN:+1 555 1234567

Same for this one, but that might be a bug, no idea.
What happen if you open the contact on nextcloud?
And edit it maybe?

Though this was supposed to fix the multiple types like TYPE=HOME,VOICE => TYPE=HOME,TYPE=VOICE, any similar contacts?

[giddyhup]

I'm directly downloading VFC files from the Contacts interface, I don't see the fixes in the raw file: TEL;TYPE="IPHONE,CELL,VOICE":

in eM Client's GUI this turns into

Here, I have to assume that is also related to the "pref":

ITEM1.EMAIL;TYPE="INTERNET,pref":jane_doe@example.com
ITEM1.X-ABLABEL:_$!<Other>!$_

[skjnldsv]

It looks like your em client is not compatible with new vcards syntax :/

[giddyhup]

Happy birthday to my favorite issue. I know it's heartless but I hope you die soon.

[Soulplayer]

Is there a way to manual fix this issue?

[deluxestyle]

yes, I would be interested in a manual fix as well if possible

[thefrip]

Same for me !!! I tried to look into the code, but not clear where to apply any sort of fix unfortunately. This is the only thing preventing me from moving from radicale/infcloud to nextcloud contacts, a real pity.

[rakekniven]

Thanks for fixing this issue. Just tested it with my NC v23.0.4 incl. contacts v4.1.0 app and it works with my iOS v15.4 devices.

Writing a message here to praise the ones who fixed it ❤️. One more thanks 🙏 .

[FackelAB]

Thank you fixing this!

[thefrip]

Same from my end, thank you so much. Long awaited fix that will allow me to simplify my infra (was using Radicale + NextCloud, can now go 100% NextCloud :-)

[RolKl]

Thanks for fixing this issue. Just tested it with my NC v23.0.4 incl. contacts v4.1.0 app and it works with my iOS v15.4 devices.

Writing a message here to praise the ones who fixed it ❤️. One more thanks 🙏 .

Which fix?
I have the same problem with exactly the same configuration, NC 23.0.4., contacts 4.1.0 and ios 15.4.
It is still there.

[rakekniven]

Which fix?

See above linked PR.

[giddyhup]

Darn. I missed the anniversary to say thanks for the fix. Well, so long old friend, you won't be missed.

[OmarWazzan]

Which fix? I have the same problem with exactly the same configuration, NC 23.0.4., contacts 4.1.0 and ios 15.4. It is still there.

@RolKl I'm experiencing that as well currently - did you ever figure it out?

[RolKl]

Sorry, the problem still exists. Now with NC contacts 4.2.0, ios 15.6 and nc 24.03.

[nicokaiser]

Since this issue cannot be re-opened for some reason, I opened a new one: #2866

[rakekniven]

Sorry, the problem still exists. Now with NC contacts 4.2.0, ios 15.6 and nc 24.03.

Have exactly the same setup and it works reliable here ... have no idea where to look ...

[OmarWazzan]

@rakekniven

I think it may have something to do with import / export logic, copied from another comment:

I also tried importing the contacts, exporting them, manually fixing the field, and then re-importing it and the issue still appeared.

However, if I imported a contact, and then reset the TYPE attribute (i.e, from mobile -> none -> mobile), then the field is properly stored.

This leads me to believe that the issue is not with all contacts, but rather with import/export of them

[5ila5]

import Function calls parseVcf:

contacts/src/store/addressbooks.js

Lines 410 to 424 in 5fd5d68

	async importContactsIntoAddressbook(context, { vcf, addressbook }) {
	const contacts = parseVcf(vcf, addressbook)
	context.commit('changeStage', 'importing')
	// max simultaneous requests
	const limit = pLimit(3)
	const requests = []
	// create the array of requests to send
	contacts.map(async contact => {
	console.info(contact)
	// Get vcard string
	try {
	const vData = contact.vCard.toString()

parseVcf calls new Contact with every single vCards:

contacts/src/services/parseVcf.js

Line 55 in d5cdb70

const contact = new Contact(vCard, addressbook)

which calls let jCal = ICAL.parse(vcard) and this.vCard = new ICAL.Component(this.jCal)

contacts/src/models/contact.js

Lines 47 to 72 in 5fd5d68

	export default class Contact {
	/**
	* Creates an instance of Contact
	*
	* @param {string} vcard the vcard data as string with proper new lines
	* @param {object} addressbook the addressbook which the contat belongs to
	* @memberof Contact
	*/
	constructor(vcard, addressbook) {
	if (typeof vcard !== 'string' || vcard.length === 0) {
	throw new Error('Invalid vCard')
	}
	let jCal = ICAL.parse(vcard)
	if (jCal[0] !== 'vcard') {
	throw new Error('Only one contact is allowed in the vcard data')
	}
	if (updateDesignSet(jCal)) {
	jCal = ICAL.parse(vcard)
	}
	this.jCal = jCal
	this.addressbook = addressbook
	this.vCard = new ICAL.Component(this.jCal)

the import function then calls const vData = contact.vCard.toString()
which leads to the additional quotes as described in my Issue for the used Library:
kewisch/ical.js#532

[JonathanBouligny]

I didn't quite know where to post this so its on both issues, I cant remember if i read this somewhere or if I made it up, whatever it worked for me.

Workaround (that worked for me) going from Apple to Nextcloud.

Export from Apple in vCard
Import into Google Contacts.
Export from Google Contacts using vCard
Import into Nextcloud

I assumed that googles code would clean up weird contact values on export which seems to be correct.

[plumped]

This issue is still pending.

If i create the contact over the iPhone (added DAV account), the contact will be saved with:

TEL;TYPE=CELL,VOICE,pref:45121542184

If i create it instead in the Nextcloud Webapp directly in contacts app it creates as follows:

TEL;TYPE="CELL,VOICE,pref";VALUE=UNKNOWN:+21323568

Which leads to problems

[stephanbogner]

I found the same as @5ila5 ... but I also noticed that the contact class actually has a toStringStripQuotes-function that could be used to fix the issue 🤔

[giddyhup]

@stephanbogner / @5ila5 - thank you for pointing this out. I just encountered this and non-dearly remembered my least favorite bug. I moved to a new Nextcloud instance and thought the smart thing to do would be to move contacts via export/import. Now, more phone number types are broken than before. : (

Should this be a new bug or can this one be opened again?

[stephanbogner]

@giddyhup
There is an open issue (#2866) but there hasn‘t been an answer from any dev yet :(