Bug 1979 - Do not drop unsupported fields when Importing Business Cards
: Do not drop unsupported fields when Importing Business Cards
Status: RESOLVED WORKSFORME
Product: Contacts
General
: unspecified
: All Linux
: Medium enhancement (vote)
: 5.0 (1.2009.41-10)
Assigned To: rtcomm@maemo.org
: contacts-bugs
:
:
:
: int-116910
  Show dependency tree
 
Reported: 2007-09-05 12:56 UTC by Nick
Modified: 2008-12-18 16:21 UTC (History)
3 users (show)

See Also:


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description Nick (reporter) 2007-09-05 12:56:12 UTC
EXPECTED OUTCOME:
If someone sends you a "complete" vcard you would expect the app to either
create the missing field, dump the data into a "misc" field for the user to
sort later or ask "what should I do with field xxx?"

ACTUAL OUTCOME:
Contacts imports the fields it has, and discards additional data.

STEPS TO REPRODUCE THE PROBLEM:
From you mobile phone, create a contact with name, phone number & snail mail
address.
Send the card via bluetooth.
Import the card into the contacts.
New contact will be created with name & phone numer, snail mail address will be
lost for ever.

OTHER COMMENTS:
Comment 1 J├Ârgen Scheibengruber nokia 2007-09-05 13:07:02 UTC
True, that would be nice. We will consider it for future versions. Thanks for
reporting this!
Comment 2 Jake Kunnari 2007-09-05 13:15:57 UTC
Changed to Enhancement. Quim Gil added to cc-field.
Comment 3 David Hagood 2008-02-05 19:15:40 UTC
It would be nicer still if the contacts app supported all the information that
Evolution Data Server supported

It would ALSO be nice if EDS were tied into Maps such that if a contact has a
snail mail address that would automatically show as a POI in Maps
Comment 4 Andre Klapper maemo.org 2008-10-11 02:53:39 UTC
For your interest, bug 3269 is about adding Street address to Contacts
application.
Comment 5 Quim Gil nokia 2008-12-18 15:19:24 UTC
Resolving this as WORKSFORME in Fremantle. Not a FIXED since unsupported fields
will be still hidden, but not WONTFIX either since the types of fields
supported increases and covers what we think are the mainstream use cases.

Showing unsupported fields is tricky, because it is a common assumption that
apps only show what they can handle, so vcards are often full of "meta-data"
that is not intended for the users eyes.

We have been thinking a while how to handle that, but the conclusion was that
all of our ideas are really targeting the "power-user" and that joe sixpack
would rather prefer to not have to care.

If there is a specific standard field that many users find is missing then we
can consider to add it to the list of supported fields.
Comment 6 Mikhail Zabaluev nokia 2008-12-18 16:21:36 UTC
(In reply to comment #5)
> all of our ideas are really targeting the "power-user" and that joe sixpack
> would rather prefer to not have to care.
> 
> If there is a specific standard field that many users find is missing then we
> can consider to add it to the list of supported fields.

Yes, I think going with a comprehensive list of well-known fields from the
vCard specification(s) should be a good approach. No obligation to display them
all, however. Blind storage and sending should not be a big problem.
Attention should be paid for fields with special semantics, like revisions,
synchronization markers etc. If we don't support those as required, they better
be omitted.