vCard issue where names, addresses, and list organization is getting messed up.

[gitmeED331]

This is a carry over from: etesync/android#244

There is an issue where Android contact list apps when interacting with Etesync (and thus this library) are creating odd behavior not seen otherwise.

Specifically using Etesync (which uses this library) and its interaction with Android contact list apps (ie. Google Contacts and Apple contacts; another user has confirmed similar behavior of sorts on linux).

Basically, when a contact is created or imported that does not contain a first/middle/last name and only contains a Organization name (with other contact details). Basically, a vCard not associated with a person, but a business entity.

Example vCard (that doesn't have a problem, not associated with Etesync or this library):

BEGIN:VCARD
VERSION:4.0
FN:
N:;;;;
ORG:Test Company
TITLE:
TEL;TYPE=work:123.456.7890
ADR;TYPE=HOME:;;123 Walnut St;NoWhere;CO;12345;United States
END:VCARD

But this same vCard when assiociated with Etesync (and thus this library) will copy the Org attribute to the FN attribute (Android -->> Etesync). But then when it comes back (Etesync -->> Android), it is copy the FN attribute to the N attribute and screwS up organization.

The Org attribute getting copied to the FN atrribute doesn't seem to be a big problem, from my reading that is required (though Google, Outlook, etc don't seem to care and ignore that requirement). It is when the N attribute gets populated with the same data stored in the Org attribute. But maybe it is bothv I don't know.

This does not occur when syncing to GMail, Outlook, or using DecSync (though DecSync seems to just store, not process, for syncing). I have not found another that does this.

This issue screws my contact list organization up pretty bad.

Another issue that goes along with this is how the address fields get messed up. In the apps, the address is divided into separate (sub) fields. When Etesync (& this library) interacts with a contact, it will copy the entire address into a single field (some times the PO Box, others into the street address along with what is already there). This screws addresses up pretty bad, will take me hours to fix, but no reason to fix it when it just get undone on the next sync.

Please see the other issue ticket on Etesync for further details: etesync/android#244

[barathrm]

Just some more context:

• etesync uses a custom fork (not sure why) of vcard4android
• I don't think the address field is messed up, but a LABEL is added which contains the entire address as one string, which maybe isn't rendered correctly by OPs apps

My theory is that vcard4android adds an FN field if it's missing (as it should according to the spec), populates it using the org property. Then some android apps (not this library, I think) add an N field and populate it using the FN field. Some android apps also display this FN property in the first/last name fields, when no N is present.

Then, in android apps, the vcard will look as if the organization property has morphed into first and last names, which is OP's ultimate problem AFAICT.

The only way I see to solve OP's problem is to not set the FN field based on the ORG property, but that would go against spec. It seems like that's what google does, according to OP's experiments in the etesync issue ticket. I guess the question to this library's maintainer is whether having a vcard represent an org without first/last names is something that's been seen or considered before or if you have any additional context. I saw that the vcard spec has a kind:org, but this doesn't really seem supported by anyone.