Etesync altering contacts upon sync #244
Comments
|
Hm, I can't reproduce this behavior. I tried reproducing this by creating a contact using the default contacts app on my phone similar to your description above. Ie, I left the name fields blank and only filled out the company, phone and location fields. I don't have an "address" field when creating a contact, only "location". I manually synced my contacts using the etesync android app and then looked at the contact on my linux PC. The contact there looks exactly as I created it. Looking at the transaction entry in the etesync app, it also looks as expected. This is the raw data stored in etesync:
You could also create a testing non-etesync-backed contact in the way that would break your etesync sync, and then export it as a vcard file and upload it here. Then others could try importing/inspect it to see if your contacts app maybe produces a contact which etesync somehow cant parse. |
|
Actually, even yours is messed up. Your example contains data in the FN (full/formal name) field. Also, your "single address field" is also an indicator of problems. I will do you one better. Here is a video ( https://u.pcloud.link/publink/show?code=XZBxAaVZNT3aERFki0yLuSLDPfhrefo6YJFX ) from start to finish of creating a contact using a brand new etesync contact list, ending with showing how things end messed up. Here is the raw data from this new contact seen in video without any additional edits post video: Note: the address is also messed up This was created in the stock contacts app. I have also tried doing things using the OpenContacts app, Simple Contacts Pro app, etc. and the exact same thing happens.
to use the web portal is not a solution for obvious reasons, but especially since even that is messed up. Here is the original raw data from a contact made via the web portal before any edits/corrections: BEGIN:VCARD Here is the same contact after trying to correct the address field via device (interestingly, it removed the jabber stuff): BEGIN:VCARD here is a link to a vcard not associated with etesync: https://u.pcloud.link/publink/show?code=XZ8qAaVZAHhd7YGfXBF6I5JaMRs2zbE7toz7 |
|
Thanks for the details! I agree, I also had the FN field added. I just didn't notice, because non of my apps seem to show that as a "name" field. Ie. the contact is shown as nameless both on android and linux 🤔 But yes, it seems to be added by etesync, creating a plain contact and exporting it doesn't have that field. It also seems like etesync adds this "TYPE" thing and a LABEL to address. As a test I created a contact with no name but an address in linux and it got imported into etesync "correctly", ie no FN field was added. The address looks as I would expect too I think: So maybe the android adapter has some issues.
I have no knowledge at all about vcard standards, but that's just how my android contacts app displays it (ie as only one item). So I dont think that in itself has anything to do with etesync, at least on my side.
that's bad... sounds like a bug for https://github.com/etesync/etesync-web
I imported this to both my etesync address book and my local phone account. The etesync import changes it similar to yours. Ie, FN is set and the address isn't duplicated exactly, but it seems like etesync adds something called Your original vcf file:
After importing to etesync
seems to seems to have kept the address as is (?), but turned I watched your video and yeah, it looks like your contacts app is automatically displaying the value of FN as the first and last names etc. That doesn't happen for me, weirdly enough: 
It seems like my contacts app stores first and last names under the I have no idea what the right behavior is, but I tend towards agreeing that ideally the android etesync adapter app shouldn't change the contact vcard from what the android contacts app generated. This is the first time I've heard of this issue, so maybe most apps simply don't render Unless someone else beats me to it I'll try to see what the code does. The etesync android app uses a library to handle the vcard stuff, and this might be a bug/weird behavior. |
|
Alright, here's the vcard standard (I think): https://datatracker.ietf.org/doc/html/rfc6350 About
From this, it sounds like, according to the standard, a vcard must have a FN property. From reading this I assume the About
So, this seems a bit similar. The purpose seems to be to provide a string which can be used by an app to summarize or display an address "as one thing". Ie. an address might consist of individual sub-items like street, city etc, but this might tell an app what to print when the address is supposed to be summarized somehow. Sooo... from the above, it sounds like adding
Yeah, I must've tested editing my vcard before syncing or something. I get the same behavior in my apps now. I think that's either it's bug in all these contacts apps though, since that's not what Edit: So I went a bit further down the rabbit hole and I think what's happening might be this: The vcard spec has a I think what might be going on is that the vcard library adds the FN field, since it's required according to the spec, and every app assumes that a vcard without But, even if I import this to my local address book (without involving etesync) it displays FN as the first and last names. Simple Contacts shows it a bit differently, but it also drops KIND. Maybe no apps actually support this? |
|
Hmm, that is strange since using these apps alone or synced to gmail, outlook, Icloud and other providers have no issue. I literally had no problem using just the org field i saw another issue ticket here that mentioned the single address fiels should be seperate fields issue and all my apps use separate address fields, including my desktop clients. I don't understand how vCard expects people to store businesses that are not related to a specific person if it is not allowing this. Is cardav and vcard separate standards? If so, maybe these apps (which would include Google, iCloud, Outlook, etc themselves) use the cardav standards? When I import that vCard, I get this: https://u.pcloud.link/publink/show?code=XZdTNaVZuo9gKiMIicSd9RmLv08JRmDN4K27 i looked up samples of vCards and they show separate address fields. https://www.w3.org/TR/vcard-rdf/#Examples I just noticed something about the vCards and don't think it is the FN field that is the problem, but rather etesync's usage of it and lack of a blank N field. For an organization with no N field input: For a personal contact: I think the FN is supposed to be populated based on priority of attributes, not directly entered. So that if first/middle/last name are entered, FN uses that attribute; but if they are empty the FN field uses the Organization field; etc down the list of titling type attributes. And since the N attribute is missing and FN is being misused, it copies the Org attribute to fill the gap. This is just me guessing with what little knowledge I have on the subject and deduction from the behavior. |
|
Running some more comparisons, I think my deduction may be correct. One thing they do is display the FN attribute (titled "display name" on the interface) and made it user selectable/editable (not many offer this as a direct editable). Here is the behavior presented: See video: https://u.pcloud.link/publink/show?code=XZBRaaVZTaogHR9Uk4bb2ovu1r8kNkItA1iV I believe this is the correct behavior that Etesync is not following but the apps are. vCard from the 3 versions: Org attribute only: N attribute only: Org and N attributes: I imported these vCards into a newly created Etesync contact list. Besides the address getting messed up on all of them, The Org only vCard is the only where it copies the Org attribute to the N attribute, which Etesync seems to see FN and N attributes as one and the same which it shouldn't. NOTE: in order for me to import all 3, I had to change the name on the N Only vCard to "Jane Doe" (hence the variance in the supplied vCards and the video). The apps couldn't tell the difference between the ones with the N attribute filled on import and merged them, duplicating fields. |
|
I was a bit confused by what you meant was the problem with the
If you mean "directly entered by a human", then yeah, I think that's what etesync does. 🤔 Ie it sets the FN field automatically based on what/whether there's something in N, ORG etc. And then apps display that FN field.
I think etesync does that as well? That's why when you don't set a N, etesync takes the ORG and puts it into FN.
Alright, so I've experimented a bit with this and read some more of the library's code. It seems that the library is adding an I've experimented what happens depending on whether Without FN: Then, no matter the import-app I get this: So it adds the FN field as expected and according to the spec. With Imported using default contacts app: Imported using Simple Contacts: So it seems like my default android app might be adding the However, the ultimate issue of the first and last name fields in apps being populated based on the |
|
Yeah, I was generally wrong about the FN field. I originally thought the FN field was the N field. Now I understand it is not, so why is N getting populated when synced with Etesync? I almost thought it might have something to do with vCard version because Google Contacts app exports version 2.1, OpenContacts and Etesync export version 4.0; but that doesn't appear to be an issue.
This is correct behavior.
If you do that the apps will show "(No Name)" and really mess things up more.
From my standpoint it is only happening in relation to Etesync since none of my other tests without Etesync are doing it (seen below). Somehow have to stop it from copying the FN to N field in the absence of the N field. I know, sounds simple but not, its the how that needs to be figured out. I created this vCard and imported it into Etesync, DecSync, Gmail, and phone Storage. Was hoping "blanking" out the FN and N fields it would help, but as you can see below it doesn't. When it imports initially, the apps treat it appropriately until sync with Etesync. The apps export looks like this before Etesync syncs, they trimmed the blanks: Once Etesync gets it before sync, its raw looks like, so before sync Etesync has already changed things: Then once Etesync syncs it with server, the Etesync vcard looks unchanged but the app export looks like this: Imported into DecSync contact list, everything looks appropriate, I get this export (exactly like the original): Imported into Gmail or phone storage, apps look appropriate, exports get this (same from both apps): The export from GMail web looks like this: So, it is not the apps copying things to the FN and N fields. I hope this helps, I don't know what else I can provide except to test things for you. |
I agree about FN, but I'm not sure about the N property, since I didn't get a
so it looks like at this point you already get the
So the vcard looks unchanged, and without a From your exports above it looks like gmail and decsync both don't touch the FN property, even though it's empty in your original vcard, while the library used by etesync does. When it sees that the FN property is empty and it sets it based on what's in the org property. I guess that's the reason it might look differently in the apps, ultimately. Whether this is correct or not, I don't know. Just from reading the spec I can see someone arguing that the etesync library does it correctly, since the spec says it must be present have have a single text value (ie not empty). But... it seems like google doesn't care. And google is big enough to maybe enforce their bend on the standard, which means that apps treat FN = first and last names etc, when present and not empty. We could make an issue ticket for this upstream (https://github.com/bitfireAT/vcard4android) or patch this in our version of the library, but it's not really up to me and I'm not sure what the correct thing to do is. But I'm not even a maintainer :D Anyways, thanks for helping debug 🙏 Maybe @tasn has an opinion on the correct behavior, but it sounds like a ticket at the upstream repo might help more since I assume that dev has more domain level knowledge on this. |
Yes, but only after interacting with Etesync, nothing else. Something else I noticed: Proton treats the FN and N attributes as one and the same (really it ignores the existence of the N attribute completely) and requires the FN attribute to be filled. Won't even allow a contact to be created/imported without FN attribute.
But why only when interacting with Etesync? I think it is multistep: at first interaction with Etesync, it adds the FN as it should; the next interaction (the sync) it adds the N? But then once the N is there, regardless of where it came from, why is Etesync not showing it in its raw data? But if it was the apps adding the FN and N attributes, why wouldn't they do it with DecSync? It's only happening with Etesync. Which I guess DecSync does not do any processing, merely manages the contact list files for syncthing to transfer the raw data. Which would explain why it doesn't have the issue.
Well, we know Google does whatever they want, no regard for anything or anyone. I will look into upstream. |
I'm pretty sure that if etesync isn't showing it in the raw data, it's not there. In other words, if it's there when exporting it using an app, but not in the etesync data, I think it's added by the app...
If I understand the code and our experiments correctly, etesync only adds the FN property. But then apps might add the N property as well, once they see the FN property, like my default contacts app (but not Simple Contacts).
Yep, I'd guess DecSync doesn't add the FN, and then the rest of the problems don't get kickstarted by that. |
|
But if the apps are adding the N, why aren't they doing it with DecSync and others? It only occurs with Etesync. So, maybe is the interaction between the apps and etrsync. The combination is the issue. |
|
Upstream ticket created: bitfireAT/vcard4android#22 |
If I understand correctly, etesync adds the |
|
Yeah, definitely hard to pinpoint. |
|
Just went through and managed to get Etesync working on my iPAD and my wife's iphone Same behavior is seen not seen before Etesync, independent of android involvement (meaning not the same address books or account) |
Edit: additional upstream ticket created: bitfireAT/vcard4android#22
=======
I have encountered an issue where Etesync is altering my contacts and screwing up address book organization and addresses.
The first part of the issue I noticed was how Etesync copies the business/company/organization to fill in the first/middle/last names (which are intentionally blank).
The second part of the issue is that Etesync is taking the address and corrupting/malforming it.
Example, lets say I create a contact for XYZ Medical Center
The contact I enter:
First name: [blank]
Middle name: [blank]
Last name: [blank]
Company: XYZ Medical Center
Phone: 123.456.7890
Address: 123 John Doe Dr
City: Tampa
State: Florida
Zip code: 12345
What Etesync does and screws up my address book on my devices:
First name: XYZ
Middle name: Medical
Last name: Center
Company: XYZ Medical Center
Phone: 123.456.7890
Address: [blank]
PO Box: 123 John Doe Dr,Tampa,Florida,12345
City: [blank]
State: [blank]
Zip code: [blank]
This is not acceptable for multiple reasons.
I am running stock on Pixel 6A (latest update). I have tried multiple contact apps and the Etesync WebApp to correct things and Etesync keeps screwing things up.
I know it has to be Etesync since I can edit the contacts and things will work just fine until the next sync. Also, if I use other options like DecSync, there is no issue. The issue only exists when Etesync is involved.
What is going on? What can be done to fix this?
Thank you
The text was updated successfully, but these errors were encountered: