[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
DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.
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?
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.
>>> 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
clients).
>>> 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