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

noreply at bugs.horde.org noreply at bugs.horde.org
Thu Aug 15 09:34:27 UTC 2013


Ticket URL: http://bugs.horde.org/ticket/12329
  Ticket             | 12329
  Updated By         | Jan Schneider <jan at horde.org>
  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

Jan Schneider <jan at horde.org> (2013-08-15 11:34) wrote:

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

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

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

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  

>>> 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ß

More information about the bugs mailing list