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.

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.

This bug isn't resolved and shouldn't be marked as such.
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.

Hallo,
Then this can be considered as the worst case that could happen in 
this situation... :-(
(see below for an idea for resolving this)
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.
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.
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ß

Yes.
How should that work? You cannot display a confirmation button during 
synchronization.

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).

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?

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.
Is this against vCard standard? (you seem to insist on standards, see below)
Okay.

Kind regards,
Anna Christina Naß

But Turba doesn't. It only supports the attributes in the original 
config/attributes.php for importing.
Again, only one cellPhone attribute is supported.
There is no IMPP attribute. And using this without an X- prefix is 
even breaking RFCs.

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ß

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

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

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

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.