We have decided that DAVdroid will take up the Android design of one address book per account, thus also allowing to sync only one addressbook per account. If you need more address books, please create several accounts.
RELATED TYPEs mappings not 1:1
-
(Using DavDroid 1.2)
The
RELATED
property withTYPE=spouse
is mapped toTYPE_PARTNER
Relation
(which refers to business partners) and notTYPE_SPOUSE
as it should.TYPE_SPOUSE
maps back toTYPE=sweetheart
andTYPE_DOMESTIC_PARTNER
maps back toTYPE=co-resident
. All these mappings are incorrect; I did not test other mappings. These should be fixed.I have searched through the source code, but did not find the location where these mappings are defined. (I found
contacts.xml
) Where can I find these mappings, so I can suggest corrected mappings? -
The values which are available in Android are not identical to those defined in VCard.
Data transfer between the VCard data class
Contact
and the Android Contacts provider is done inAndroidContact
, so you can also find the mappings there (populateRelation
: Android → data object;insertRelation
: data object → Android).Where do you know from that “partner” refers to business partners? The documentation is not very meaningful, so we had to play puzzle to guess which Android values have the same or a similar meaning as their VCard counterparts.
-
@rfc2822 said in RELATED TYPEs mappings not 1:1:
The values which are available in Android are not identical to those defined in VCard.
Data transfer between the VCard data classContact
and the Android Contacts provider is done inAndroidContact
, so you can also find the mappings there (populateRelation
: Android → data object;insertRelation
: data object → Android).So, we have 14 types in Android:
TYPE_ASSISTANT, TYPE_BROTHER, TYPE_CHILD, TYPE_DOMESTIC_PARTNER, TYPE_FATHER, TYPE_FRIEND, TYPE_MANAGER, TYPE_MOTHER, TYPE_PARENT, TYPE_PARTNER, TYPE_REFERRED_BY, TYPE_RELATIVE, TYPE_SISTER, TYPE_SPOUSE
. Of these,TYPE_REFERRED_BY
is currently the only one not dealt with bypopulateRelation
.We have 20 types in vCard:
contact, acquaintance, friend, met, co-worker, colleague, co-resident, neighbor, child, parent, sibling, spouse, kin, muse, crush, date, sweetheart, me, agent, emergency
. Of these, 9, namelychild, co-resident, crush, date, spouse, sweetheart, friend, kin, parent
are dealt with byinsertRelation
. Meaning: see http://gmpg.org/xfn/11The 5 clear 1:1 type correspondences I see are:
(TYPE_CHILD, child)
,(TYPE_FRIEND, friend)
,(TYPE_PARENT, parent)
,( TYPE_RELATIVE, kin)
,(TYPE_SPOUSE, spouse)
. Of these(TYPE_SPOUSE, spouse)
is currently not dealt with correctly, and should therefore be an uncontroversial fix.For all the other types, I don’t think trying to make one-way correspondences is a good idea, as this will lead to data loss (e.g., spouse -> TYPE_PARTNER -> sweetheart). I think the only reasonable approach is to use the label option for those (both Android and vCard have this option), which breaks localization, but does allow full 1:1 correspondences in both directions.
Convincing Google and the VCARDDAV people to harmonize is the next step…
Where do you know from that “partner” refers to business partners? The documentation is not very meaningful, so we had to play puzzle to guess which Android values have the same or a similar meaning as their VCard counterparts.
I thought it was, but I am now not at all sure any more about that.
-
@equaeghe said in RELATED TYPEs mappings not 1:1:
I think the only reasonable approach is to use the label option for those (both Android and vCard have this option), which breaks localization, but does allow full 1:1 correspondences in both directions.
I can support this only in one way (VCard → Android custom type + label), because the VCard standard is more universal than the Android values. So, in my opinion, values should be transformed into well-defined VCard values whenever possible.
For instance, Android
brother
/sister
should be coded as VCardsibling
because only then other user-agents can process this value. Maybex-brother
/x-sister
could be added additionally – so DAVdroid can set Android sister/brother again accordingly.In the other direction, VCard values which are not easy to map, could be stored as Android custom type + label. (But when uploading again, those values must not be prefixed with
x
; otherwise, the VCardcolleage
would become an Android custom typecolleage
, would become anx-colleage
when uploaded).I must admit that I don’t have put much efforts into these algorithms yet because I haven’t seen anyone actually use this “feature”. May I ask what your use case is?
Would it be possible that you provide a patch for the changes discussed above?
-
@rfc2822 said in RELATED TYPEs mappings not 1:1:
I must admit that I don’t have put much efforts into these algorithms yet because I haven’t seen anyone actually use this “feature”. May I ask what your use case is?
Well, I’d like to sync relations such as spouse, child, etc. to keep track of (names) of people important to my friends. Using vdirsyncer, I can edit things VCARD-side if needed.
Would it be possible that you provide a patch for the changes discussed above?
I forked the project on GitLab and made some straightforward changes (so nothing involving labels) that should make the translation more correct. This results in some less correspondences being filled-in, but I think it is better this way. Perhaps even some more translations should be left out, i.e., those that lead to information loss upon roundtripping.
I’ve tried to generate a merge request, but that failed, so perhaps that functionality is disabled:
https://gitlab.com/equaeghe/vcard4android/commit/1e81a5294c5dd2d24401fa81d26a2d75db60b74e
-
@equaeghe said in RELATED TYPEs mappings not 1:1:
@rfc2822 said in RELATED TYPEs mappings not 1:1:
Would it be possible that you provide a patch for the changes discussed above?
I forked the project on GitLab and made some straightforward changes (so nothing involving labels) that should make the translation more correct. This results in some less correspondences being filled-in, but I think it is better this way. Perhaps even some more translations should be left out, i.e., those that lead to information loss upon roundtripping.
I’ve tried to generate a merge request, but that failed, so perhaps that functionality is disabled:
https://gitlab.com/equaeghe/vcard4android/commit/1e81a5294c5dd2d24401fa81d26a2d75db60b74e
Is there any hope that this will get merged?
-
Any hope of movement on this issue?
-
Just stumled over this issue. I do youth work and would like to add kids’“mother” -and “father”'s names to their contact. However, as discussed above, there is no “correct” translation from android to vcard which causes to become both a “parent” relation.
Here a test, how the android relation do resolve:
FN:Relationtest N:;Relationtest;;; RELATED;TYPE=co-worker;VALUE=text:Assistant RELATED;TYPE=sibling;VALUE=text:Brother RELATED;TYPE=child;VALUE=text:Child RELATED;TYPE=spouse;VALUE=text:Domestic Partner RELATED;TYPE=parent;VALUE=text:Father RELATED;TYPE=friend;VALUE=text:Friend RELATED;TYPE=co-worker;VALUE=text:Manager RELATED;TYPE=parent;VALUE=text:Mother RELATED;TYPE=parent;VALUE=text:Parent RELATED;TYPE=spouse;VALUE=text:Partner RELATED;VALUE=text:Referred by RELATED;TYPE=kin;VALUE=text:Relative RELATED;TYPE=sibling;VALUE=text:Sister RELATED;TYPE=spouse;VALUE=text:Spouse REV:20200511T200233Z END:VCARD
Why can’t you just make unclear relation type mapping a custom one, these way the data would actually not be changed with synchronisation which took me quite a time to find out. I always wondered, why these relation aren’t the same anymore on nextcloud after synchronisation.