maemo.org Bugzilla – Bug 1979
Do not drop unsupported fields when Importing Business Cards
Last modified: 2008-12-18 16:21:36 UTC
You need to
before you can comment on or make changes to this bug.
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?"
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
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.
True, that would be nice. We will consider it for future versions. Thanks for
Changed to Enhancement. Quim Gil added to cc-field.
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
For your interest, bug 3269 is about adding Street address to Contacts
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.
(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