6.0.0-git
2019-03-19

[#12329] Many fields are ignored when importing vCard files
Summary Many fields are ignored when importing vCard files
Queue Turba
Queue Version 4.1.0
Type Bug
State Resolved
Priority 2. Medium
Owners jan (at) horde (dot) org
Requester acn (at) annachristina (dot) eu
Created 2013-06-10 (2108 days ago)
Due
Updated 2016-12-09 (830 days ago)
Assigned 2013-06-13 (2105 days ago)
Resolved 2013-06-20 (2098 days ago)
Milestone
Patch No

History
2016-12-09 11:21:17 Jan Schneider Deleted Original Message
 
2013-08-16 14:27:58 spam (at) ancow (dot) no-ip (dot) org Comment #12 Reply to this comment
The first solution, which the term "simply" refers to, would only 
require an additional field in the database and having the 
synchronisation pull data from there once for the outgoing 
synchronisation and writing whatever data it would otherwise discard 
in there.

Compared to the other solutions, which actually would require a 
complete re-implementation of the data storage aspect, this *is* simple.


And this bug still is critical and unresolved.
2013-08-16 14:02:39 Jan Schneider Comment #11 Reply to this comment
Using the word "simply" in any of the suggested "solutions" is 
exaggerating big time. Any of those would require a complete 
refactoring of either the Turba storage layer, the synchronization 
layer, or both.
2013-08-16 13:48:18 spam (at) ancow (dot) no-ip (dot) org Comment #10 Reply to this comment
This bug isn't resolved and shouldn't be marked as such.
The biggest problem in my opinion is that these values are moved to
/dev/null without ANY notice to the user.

The user should be informed that his/her data is trashed or should be
given some way of resolving this issue.
How should that work? You cannot display a confirmation button 
during synchronization.
In the short term, until this is properly fixed, you should abort the 
synchronisation to prevent data loss. This is not just the correct 
behaviour, this would also point the user to the problem rather than 
making them have to debug where exactly their data is discarded.


One way to prevent data loss would be to provide an extra field in the 
storage backend that would simply hold all the data turba doesn't know.
Another would be what seemingly every other program I've used for 
synchronisation so far does: store the incoming vCard separately, 
update the recognised fields right before syncing and simply send that 
vCard during sync.
Finally, you could simply operate solely on vCards. While this is 
probably slower, it would avoid the problem of not being able to store 
unknown data completely. And you could always cache the recognised 
fields in the database, reducing the performance hit.
2013-08-15 09:47:23 acn (at) annachristina (dot) eu Comment #9 Reply to this comment
Hallo,
Does this mean that if I would use Turba as my primary address book
and connect some other device via CardDAV and add another phone
number for "cell phone" from there (people can have multiple cell
phones as well as multiple home or work phones nowerdays), this
number will move to /dev/null without notice?
Yes.
Then this can be considered as the worst case that could happen in 
this situation... :-(
(see below for an idea for resolving this)
The user should be informed that his/her data is trashed or should be
given some way of resolving this issue.
How should that work? You cannot display a confirmation button 
during synchronization.
You could collect the data that could not be mapped to the Turba 
fields and present something like a "import report".
And in that report you could give the option to map the data to other 
fields (by clicking links or drop-down-boxes) or move the information 
to the "note" field.

The information sould NEVER be trashed -- or the system is not 
trustworthy any longer.
Again, only one cellPhone attribute is supported.
Is this against vCard standard? (you seem to insist on standards, see below)
No vCards can have unlimited numbers of attributes. Which doesn't 
mean that address books must have them too.
The other address book applications maybe have arrays of "TEL" fields 
where each element has the option of specifying the kind of telephone 
number.
I thought that Turba isn't that limited any longer.
The only solution to this problem is to not have a fixed address 
book scheme, but allow users to create their own schemes. This is 
much easier possible where each user has his own data storage 
(desktop clients).
Which renders Turba useless as a way of synchronising data -- as it 
cannot be trusted to move my data without losing it.

The solution could be that you also support arrays of data elements.

Kind regards,
Anna Christina Naß
2013-08-15 09:34:27 Jan Schneider Comment #8 Reply to this comment

[Show Quoted Text - 12 lines]
Yes.
The biggest problem in my opinion is that these values are moved to 
/dev/null without ANY notice to the user.

The user should be informed that his/her data is trashed or should 
be given some way of resolving this issue.
How should that work? You cannot display a confirmation button during 
synchronization.

[Show Quoted Text - 9 lines]
No vCards can have unlimited numbers of attributes. Which doesn't mean 
that address books must have them too.

The only solution to this problem is to not have a fixed address book 
scheme, but allow users to create their own schemes. This is much 
easier possible where each user has his own data storage (desktop 
clients).

[Show Quoted Text - 9 lines]
2013-08-15 09:26:15 acn (at) annachristina (dot) eu Comment #7 Reply to this comment
Hallo,
I've exported this card from ownCloud, which simply shows more than
one "cell" entry, just as my iDevices do.
But Turba doesn't. It only supports the attributes in the original 
config/attributes.php for importing.
Does this mean that if I would use Turba as my primary address book 
and connect some other device via CardDAV and add another phone number 
for "cell phone" from there (people can have multiple cell phones as 
well as multiple home or work phones nowerdays), this number will move 
to /dev/null without notice?

The biggest problem in my opinion is that these values are moved to 
/dev/null without ANY notice to the user.

The user should be informed that his/her data is trashed or should be 
given some way of resolving this issue.
From another VCARD, Turba ignores the TEL-field of type "OTHER":

(only the TEL lines)
TEL;TYPE=CELL;TYPE=VOICE:0179-4722993
TEL;TYPE=OTHER;TYPE=VOICE;TYPE=pref:089-12035482
Again, only one cellPhone attribute is supported.
Is this against vCard standard? (you seem to insist on standards, see below)
ITEM2.IMPP;X-SERVICE-TYPE=None;TYPE=pref:x-apple:123456789
ITEM3.IMPP;X-SERVICE-TYPE=None:x-apple:somename
There is no IMPP attribute. And using this without an X- prefix is 
even breaking RFCs.
Okay.

Kind regards,
Anna Christina Naß
2013-08-15 09:17:45 Jan Schneider Comment #6 Reply to this comment

[Show Quoted Text - 27 lines]
But Turba doesn't. It only supports the attributes in the original 
config/attributes.php for importing.
From another VCARD, Turba ignores the TEL-field of type "OTHER":

(only the TEL lines)
TEL;TYPE=CELL;TYPE=VOICE:0179-4722993
TEL;TYPE=OTHER;TYPE=VOICE;TYPE=pref:089-12035482
Again, only one cellPhone attribute is supported.
The first one is shown in Turba, the second one is (without notice!! 
what is the worst in my opinion!) just ignored.

Also, the following fields are ignored, I would have expected to see 
them as "Instant Messenger" fields:

ITEM2.IMPP;X-SERVICE-TYPE=None;TYPE=pref:x-apple:123456789
ITEM3.IMPP;X-SERVICE-TYPE=None:x-apple:somename
There is no IMPP attribute. And using this without an X- prefix is 
even breaking RFCs.
Thank you for helping to resolve this issue.

Kind regards,
Anna Christina Naß
2013-08-15 08:55:59 acn (at) annachristina (dot) eu Comment #5 Reply to this comment
Hallo,

Today I've imported some more contacts to my address book and (thank 
god) I've checked some items if they have been imported correctly.

In the following VCARD, Turba has simply ignored (without notice) the 
second cellphone entry:

BEGIN:VCARD
VERSION:3.0
PRODID:-//Apple Inc.//iOS 6.1.3//EN
N:LastName;FirstName;;;
FN:FirstName LastName
EMAIL;TYPE=INTERNET;TYPE=HOME;TYPE=pref:xxx@example.com
TEL;TYPE=HOME;TYPE=FAX;TYPE=pref:011-123456789
TEL;TYPE=CELL;TYPE=VOICE:0176-123456789
TEL;TYPE=CELL;TYPE=VOICE:0172-123456789
TEL;TYPE=HOME;TYPE=VOICE:011-4567891
TEL;TYPE=WORK;TYPE=VOICE:011 7891234
ITEM1.ADR;TYPE=HOME;TYPE=pref:;;Street Nr;City;;12345;Country
BDAY;VALUE=date:1911-01-01
REV:2013-04-24T15:40:55+00:00
UID:deadbeef-e7c7-4fa2-97cb-63bd2c3db018
END:VCARD

I've exported this card from ownCloud, which simply shows more than 
one "cell" entry, just as my iDevices do.

From another VCARD, Turba ignores the TEL-field of type "OTHER":

(only the TEL lines)
TEL;TYPE=CELL;TYPE=VOICE:0179-4722993
TEL;TYPE=OTHER;TYPE=VOICE;TYPE=pref:089-12035482

The first one is shown in Turba, the second one is (without notice!! 
what is the worst in my opinion!) just ignored.

Also, the following fields are ignored, I would have expected to see 
them as "Instant Messenger" fields:

ITEM2.IMPP;X-SERVICE-TYPE=None;TYPE=pref:x-apple:123456789
ITEM3.IMPP;X-SERVICE-TYPE=None:x-apple:somename

Thank you for helping to resolve this issue.

Kind regards,
Anna Christina Naß

2013-06-20 11:10:58 Jan Schneider State ⇒ Resolved
 
2013-06-20 11:10:54 Git Commit Comment #4 Reply to this comment
Changes have been made in Git (master):

commit bcd352400c3c6300b17c6877094e1e583bcea8e1
Author: Jan Schneider <jan@horde.org>
Date:   Thu Jun 20 13:09:49 2013 +0200

     [jan] Set generic 'phone' attribute when importing from vCard 
(Bug #12329).

  turba/docs/CHANGES                   |    1 +
  turba/lib/Driver.php                 |    2 +
  turba/package.xml                    |    2 +
  turba/test/Turba/Unit/ImportTest.php |   61 
++++++++++++++++++++++++++++++++++
  4 files changed, 66 insertions(+), 0 deletions(-)

http://git.horde.org/horde-git/-/commit/bcd352400c3c6300b17c6877094e1e583bcea8e1
2013-06-20 11:10:48 Git Commit Comment #3 Reply to this comment
Changes have been made in Git (master):

commit c32d56602ce3819cdabfd543de7b1eb29ac06c0b
Author: Jan Schneider <jan@horde.org>
Date:   Thu Jun 20 13:08:40 2013 +0200

     [jan] Fix returning multiple attribute properties of the same 
name (Bug #12329).

  framework/Icalendar/lib/Horde/Icalendar.php |   10 +++++++++-
  framework/Icalendar/package.xml             |    4 ++--
  2 files changed, 11 insertions(+), 3 deletions(-)

http://git.horde.org/horde-git/-/commit/c32d56602ce3819cdabfd543de7b1eb29ac06c0b
2013-06-14 09:20:12 Git Commit Comment #2 Reply to this comment
Changes have been made in Git (master):

commit 1dcfd09e61865804131b43eee2efd6d03c229a51
Author: Jan Schneider <jan@horde.org>
Date:   Thu Jun 13 18:19:16 2013 +0200

     [jan] Remove group identifiers from attribute types (Bug #12329).

  framework/Icalendar/lib/Horde/Icalendar.php |    2 +-
  framework/Icalendar/package.xml             |    4 ++--
  2 files changed, 3 insertions(+), 3 deletions(-)

http://git.horde.org/horde-git/-/commit/1dcfd09e61865804131b43eee2efd6d03c229a51
2013-06-13 16:08:00 Jan Schneider Assigned to Jan Schneider
State ⇒ Assigned
 
2013-06-10 10:07:01 acn (at) annachristina (dot) eu Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 2. Medium
Summary ⇒ Many fields are ignored when importing vCard files
Queue ⇒ Turba
Milestone ⇒
Patch ⇒ No
New Attachment: Anna_Christina_Naß.vcf
Reply to this comment
As written on the mailing list:

When importing a vCard file containing one or many contacts that I
have exported from ownCloud, the contacts are created but most fields
(phone numbers, addresses ...) are NOT imported.

I've attached one example that I exported from ownCloud. I have only
changed personal information using "Notepad".
After importing this specific file into Turba, the same effect is
shown as with the unedited export file.

Saved Queries