GNOME Bugzilla – Bug 313221
Import of vcards misses type information
Last modified: 2013-09-14 16:48:54 UTC
Please describe the problem: When importing a vcard, the adresses are only taken, if the adress is listed as: "LABEL;TYPE=<home|work>,<other tags>:<adress>" e.g. "LABEL;TYPE=home,postal,intl,parcel:5th Avenue 3" is accepted, while "LABEL;TYPE=postal,intl,parcel,home:5th Avenue 3" is not accepted. But those definitions of LABEL are allowed by RFC 2426 Steps to reproduce: 1. Take a vcard with with an adresse defined as above 2. Import it in evolution 3. Actual results: The adress is not imported into evolution Expected results: I want that adress in the adress field of evolution Does this happen every time? Yes Other information: I love evolution!
can you attach a sample vcard?
Created attachment 50614 [details] Sample vcard with extended LABEL tag The listed adresses do not get imported. There is a problem with parsing the listed TYPE information.
Moving out of NEEDINFO as vCard is attached.
From IRC, another usecase fdv: anybody familiar with how evolution handles vcards from the db files? fdv: TEL;TYPE=HOME: and TEL;TYPE=WORK: are apparently not handled correctly in 2.2.3. Is this fixed in later versions? fdv: I synced my phone using multisync fdv: and only cell phone numbers were mapped correctly fdv: when I later edited the db file manually and changed TEL;TYPE=(HOME|WORK): to TEL;TYPE=(HOME|WORK);TYPE=VOICE;X-EVOLUTION-UI-SLOT=1:, everything went fine fdv: cell numbers apparently didn't need this extra info
importing of attached vcard did not import address fields.
Created attachment 87712 [details] [review] evolution proposed patch
Created attachment 87714 [details] [review] evolution-data-server proposed patch
Both patches contains changes where I added loops for testing all parameter values, not only first in the values list. (After calling of e_vcard_attribute_param_get_values function, but not everywhere.) patches partially solve bug #427469
(In reply to comment #9) > Both patches contains changes where I added loops for testing all parameter Im worried much about the performance hit here because of the loops in the lower level functions. It applies to the patches at bug #427468 also.
I think here is no other correct solution for this, because one could have multiple values in one parameter, in any order, in the list and you need to test all of them when you're looking for exact value(s). Sorting values in such a way that evolution could understand it (like put HOME/WORK/OTHER TYPE values always as the first) is like a workaround, not a solution, I think. Do you really think bug #427468? Some performance hit could be found in bug #427469 in comment #13 pat, with that testing for duplicities, that's right. I didn't found better place where to do this thing. (Maybe there could be same testing for duplicities when adding values to param.) Nevertheless, we may rather discuss this at bug #427469?
EDS part looks good.
Commit this aswell please.
e-d-s part committed to trunk. Committed revision 7924. evo part committed to trunk. Committed revision 33960.