[Tickets #12329] Re: Many fields are ignored when importing vCard files

[noreply at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/12329
------------------------------------------------------------------------------
  Ticket             | 12329
  Updated By         | acn at annachristina.eu
  Summary            | Many fields are ignored when importing vCard files
  Queue              | Turba
  Version            | 4.1.0
  Type               | Bug
  State              | Resolved
  Priority           | 2. Medium
  Milestone          |
  Patch              |
  Owners             | Jan Schneider
------------------------------------------------------------------------------


acn at annachristina.eu (2013-08-15 09:47) wrote:

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ß