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

* Your Email Address
* Spam protection	Enter the letters below: .___.. .. .. .. , _/ \|\/\|\| \|\|_/ \./ ./__.\| \|\|__\|\| \ \|
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? > > 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ß >
Attachment
Watch this ticket

Saved Queries