Contacts won't display address in column when VCard uses lower case TYPE

#1

In the eM Client Address book, when I import a vcard that contains an address with a lower case TYPE (like “home”), the contact address is correctly displayed in the contact editor, but it is not displayed in the address column of the list view.  If the vcard has an upper case TYPE (like “HOME”) then the address is shown correctly in both places.   Is it possible that you are doing a case-sensitive test in the List View when you should be doing a case-insensitive test?

I could solve my issue just by using a text editor to fix these cases, but this issue is also occurring when syncing to my CardDAV server because my Android client changes the case of the TYPE attribute. :frowning:  So every time I change a card on android, the address disappears from the eM Client list view.

ADR;TYPE=HOME:  vs. ADR;TYPE=home:

Attached is a screen shot that demonstrates the problem.   
Thanks!

#2

Hello Chris,
we’re already working on a fix for this behavior and it should be included in one of the nearest updates.

Regards,
Olivia

1 Like
#3

Hi good morming,
this problem distructs most of my contacts. Most of them got 2 or more addresses after sync with Synology Contacts and my Samsung S8. I had to edit over 100 addresses and after every sync there will be new ones.
This problem (and some other in context of vcard and types) ist now over 3 years old. When will you correct this disappointing problems? I cannot understand that you ignore this over such a long time.
Greetings

Btw.: im now using V8, but same problem.

#4

Hi,
Just FYI, I believe the specific issue I originally reported in this thread has been fixed. Possibly in v7.0.28822.0 (Feb 1, 2017). I no longer experience the issue that I described. It is possible that you may be seeing a different issue. Good luck! -C

#5

Hi Chris,

Thank you for your answer, but is see a problem with the entries ADR;TYPE=HOME or TYPE=WORK.

I have my own CardDAV-Server (Synology Contacts), a Samsung S8 (with DAVx5) and EMClient. I tried the following:

  • i exported all contacts from EMClient and Synology as vCard-files
  • i compared every contact (i reduced the number of contacts)
  • i corrected all error (home-> HOME, work->WORK)
  • i deleted all extra attributes (like TYPE=x-…, …)
  • i deleted all contacts from every device
  • i imported all contacts from a single vCard-file … then synced all devices

Result: all was ok

Then i edited one contact in EMClient. Result: all was ok, the changes synced in all devices
Then i edited in Synology Contacts. Result: all was ok
But now i edited one contact in my Samsung S8. Result: in Synology Contacts the data is ok (i exported the vCard), but the entry address-type now was written in lowercase like this: ADR;TYPE=home and an additional line with LABEL;TYPE=home:. In EMClient i got two addresses. One with ADR;TYPE=home and the same Address with ADR;TYPE=TYPE.

So i gues DAVx5 is changing the attribute of TYPE in lowercase, adds an additonal line (LABEL;…) and EMClient adds a new ADR-line to the vCard, because it cannot read the line with TYPE=home and the additional line LABEL (which could be ignored).

After every snc i get more and more addresses like described above. So who is doing wrong? DAVx5 (the additional LABEL is allowed) or EMCient?

#6

vCard in CardDAV-Server before Sync:

BEGIN:VCARD
VERSION:3.0
PRODID:+//IDN bitfire.at//DAVx5/3.2.1.3-gplay ez-vcard/0.11.0
UID:fa9fbe9a-81fe-4a10-b048-b2476686f472
ADR;TYPE=HOME:;;street 1;town;region;plz;Deutschland
BDAY:1960-01-01
CATEGORIES:Bekannte
EMAIL;TYPE=HOME,PREF:mailtome@yahoo.de
FN:Bxxxxx Gxxxxx
N:Gxxxxx;Bxxxxx;;;
REV:2020-07-28T14:18:39Z
SORT-STRING:Bxxxxx Gxxxxx
TEL;TYPE=HOME:+49 600000 00000
TEL;TYPE=CELL:+49 160 00000000
END:VCARD

vCard in CardDAV-Server after Sync:

BEGIN:VCARD
VERSION:3.0
PRODID:+//IDN bitfire.at//DAVx5/3.2.1.3-gplay ez-vcard/0.11.0
UID:fa9fbe9a-81fe-4a10-b048-b2476686f472
ADR;TYPE=home:;;street 1;town;region;plz;Deutschland
BDAY:1960-01-01
CATEGORIES:Bekannte
EMAIL;TYPE=home,pref:mailtome@yahoo.de
FN:Bxxxxx Gxxxxx
---->>> LABEL;TYPE=home::;;street 1\ntown\nregion\nplz\nDEUTSCHLAND
N:Gxxxxx;Bxxxxx;;;
REV:2020-07-28T14:18:39Z
SORT-STRING:Bxxxxx Gxxxxx
TEL;TYPE=home:+49 600000 00000
TEL;TYPE=cell:+49 160 00000000
END:VCARD

vCard in EMClient after Sync:

BEGIN:VCARD
VERSION:3.0
PRODID:-//MailClient.VObject/7.2.40748.0
UID:fa9fbe9a-81fe-4a10-b048-b2476686f472
ADR;TYPE=home:;;street 1;town;region;plz;Deutschland
---->>>> ADR;TYPE=TYPE:;;street 1;town;region;plz;DEUTSCHLAND
BDAY;VALUE=date:19600101
CATEGORIES:Bekannte
EMAIL;TYPE=home,PREF:mailtome@yahoo.de
FN:Bxxxxx Gxxxxx
N:Gxxxxx;Bxxxxx;;;
REV:2020-07-28T14:18:39Z
SORT-STRING:Bxxxxx Gxxxxx
TEL;TYPE=HOME:+49 600000 00000
TEL;TYPE=CELL:+49 160 00000000
END:VCARD
#7

I have tested this and found that eM Client 8.0.2951 interprets the LABEL as a separate address (“Type Addresse”):

BEGIN:VCARD
VERSION:3.0
PRODID:+//IDN bitfire.at//DAVx5/3.3-beta1 ez-vcard/0.11.0
UID:37a61241-24f6-48fa-be02-a0fa23db483f
FN:Test Contact
N:;Test Contact
ADR;TYPE=work:;;Test Street 123
LABEL;TYPE=work:Test Street 123
REV:2020-07-30T09:28:40Z
END:VCARD

→

em
em1059×524 25.1 KB

If I use another value for the LABEL, it also appears as Type Adresse.

As I understand RFC 2426 LABEL, it represents the formatted text of the corresponding ADR (I would have linked it, but I’m not allowed to post more than two links):

Type purpose: To specify the formatted text corresponding to delivery address of the object the vCard represents.

ADR definition:

Type purpose: To specify the components of the delivery address for the vCard object.

So as I understand it, the LABEL is not a separate address, but the “display-value” of ADR. This is also how it is used by ez-vcard and other clients/Web interfaces we have tested. It also seems a hint to me that vCard 4 has re-defined the LABEL as a parameter for ADR to work exactly like that.

@ emClient people: Do you agree with that or did I overlook something?

PS I think this topic should be separated from the original thread. It’s not related to upper/lower case in any way.

#8

Exactly what i see here!