Overview on Gitlab issue #155 contact import via vcf file to e.drive doesn't work

The issue is 1,5 years old and I’ve seen nothing new in this forum in 2020.

If it can wait for so long shall we still consider it as an issue?

(Yes in my opinion. Is it not something that any new /e/ account user faces?)

@harvey186 @JOHAAANNS @Bernd15 @roncos @Superman

1 Like

Hi @cedricoola are these the issues you are mentioning. I agree it has been ‘open’ for too long as an issue. Frequently we have new users run into this bug. Let me start a thread - again- with the developers to resolve this.

1 Like

Hi @Manoj, thanks.
#995 originated from #155 that I was mentioning
#972 raises the same issue.
The issue is being experienced in Nextcloud (ecloud).
I don’t know how closely related the others of your list are, as I don’t know what the root cause is.

We are working on implementing NextCloud18 features on to ecloud. At present under testing. Expect a resolution to this issue in that. No exact ETA’s for now though we plan to release it in July.

1 Like

Still no success today, @Manoj
I tried but with a new address book that I created. I first thought of doing it with my default address book (the one named ‘Contacts’ by default) but my contacts are already in there, so I’m not going to import them again, and there is no option to delete the default address book
After choosing to import to this newly created address book, I get this: 857 faulty contacts.


(I’m not hiding the numbers because they are not real numbers)

@harvey186 @JOHAAANNS @Bernd15 @roncos @Superman you opened these topics about this same bug, reported in Gitlab under #995 formerly #155, and #972 raises the same issue):
https://community.e.foundation/t/vcf-import-to-edrive-doesnt-work
https://community.e.foundation/t/import-ics-erreurs-multiple
https://community.e.foundation/t/keine-kontakte-in-der-cloud
https://community.e.foundation/t/bulk-upload-of-contacts-to-ecloud-global

Raising this topic with the dev team again to investigate. Will have them contact you in case they want details.

Hi, just to note I recently imported a vcf file successfully

How many contacts did you have in this vcf. I had tried some time back with about 50 contacts and did not have any issues. My guess is the bug shows up when there are a large number of contacts in the vcf.

I had tried with 857 contacts but now I tried with a vcf that contains 53 contacts and the problem remains.

How are you creating the .vcf and are you able to import it in any other tool or in a place like google contacts…assuming you are trying to get the contacts from there.

There was some discussion around this in the dev team and one of the findings was that nextcloud expects vcf in vcard 3.0. Some old apps would export in 2.1 format. This would throw an error on ecloud / nextcloud . If you try creating an vcf from say google contact or other app in 3.0 format and then import it into ecloud it should work.

My vcf file was created by the contact app that is preinstalled on /e/. Will check tonight the file format version.
Earlier, in the era the bug had been reported (1.5 years ago that is) i remember my vcf came from Google Contacts.

@Manoj my file is in vcard 2.1.
So we have a problem with the contacts app preinstalled on /e/ that exports contacts into this old version, correct? In fact it’s a new problem, not the same. Can we fix that asap?
I confirm the import is working fine with a vcard 3.0 file.

Pl can you add this point to the issue in gitlab - one of the links given above. That would be good enough to get the Dev team to update vcard to the current version.

Done: #972. Please involve more developers if you think @rhunault is not the right person, as he is alone in the Gitlab issue for now.

:slight_smile: @rhunault assigns the bugs to the developers. Will share the details with him tomorrow so that it can be assigned to a developer to resolve.

1 Like

Well, when I see @rhunault opening a ticket 10 months ago but no follow-up, to me it feels a bit like he’s not really taking ownership.

As you may be aware in a software development environment especially as a project manager there are a lot of variables which come into the picture. What I have seen in my experience is that at time bugs which are critical are the easiest to fix while those that appear low priority require elaborate design changes! There are more than 800 open bugs in the gitlab. Every user will push for bugs they have raised or is important to them. The Managers and Tech Leads need to prioritize bug resolution based on the criticality of the issue , availability of the developer , overall impact to the product…While all this may seem as an excuse to delay the closure it is not. . As always will discuss with him and other team members on working on quickly resolving old open issues.

So what did @rhunault say? Classify it as requiring big design changes and postpone it even further?