make sure that multi-line phone number records are correctly handled by the contacts app

[j-ed]

Expected behavior

The contacts app should be able to handle multi-line phone number and address entries in VCARD records correctly.

Current behavior

The contacts app is currently not able to handle multi-line phone number and address entries. If these kind of entries exist in a record, the field labels are not displayed correctly (empty field). Additionally multi-line entries are not completely deleted if a phone number or address is removed from a record.

Steps to reproduce

1. Make sure that a multi-line phone number entry exists in a contact record, like e.g. (I think these kind of entries are sometimes created by Apple devices):

t5ad3h.TEL;TYPE=pref:+49 69 333 - 4444
t5ad3h.X-ABLabel:WORK;VOICE;PREF

ITEM2.TEL:+49 69 333 - 5555
ITEM2.X-ABLabel:WORK;FAX

ITEM1.X-ABADR:de
ITEM1.ADR;TYPE=WORK,PREF:;;My street 3;My City ...

2. Open the contacts app and check what field label is displayed in front of the phone numbers.
   Usually an empty label is displayed instead of WORK or WORK FAX.

3. delete e.g. the phone number entry +49 69 333 - 4444 and check what happens with the VCARD record, by exporting it to a file. You will see, that e.g. the line t5ad3h.X-ABLabel:WORK;VOICE;PREF will still persist in the record although the phone number has correctly been deleted.

Environment

Server Configuration

OS: Linux 3.2.84
Web server: Apache2 2.4.25
Database: MariaDB 5.5.54
PHP version: 5.6.29
Nextcloud version: 11.0.1
Contacts app version: 1.5.3

Client Configuration

Browser: Mozilla Firefox 51.0.1
Operating system: Windows 7

[j-ed]

This seems to be a general problem, because the same behavior can be seen with URL entries. After deleting the URL entry, the X-ABLABEL part persists in the record, e.g.:

9HELBN.URL;VALUE=URI:http://www.github.com
9HELBN.X-ABLABEL:_$!<HomePage>!$_

[irgendwie]

just some references for developers:

• 10fa229
• https://alessandrorossini.org/the-sad-story-of-the-vcard-format-and-its-lack-of-interoperability/
• https://www.w3.org/2002/12/cal/vcard-notes.html

[skjnldsv]

Duplicate of #42