On Sun, 2010-12-12 at 14:32 -0500, Jeff wrote: > > That is odd. Can you export the address book as vCard and look at the > > difference between an entry where phone numbers appear and entries > > where they don't? > > My first/gut guess is the X-EVOLUTION-UI-SLOT attribute of the TEL > > element either having a null/conflicting value in the existing vCard > > component and the save from Evolution proper causes a recalculation of > > that value. > Attached to this message is a censored+annotated vcf file that contains > some of the problematic contacts... you seem to be right about the > X-EVOLUTION-UI-SLOT thing. Why does evolution even need it?
It shouldn't "need it", but it uses it to maintain the field sort order. Because users will tend to muscle-memory the field locations; it make a nice usability improvement. I was never aware that absence create an issue but it is pretty easy to understand how that might inadvertently happen. > But as you can see, this is not limited to phone numbers... > I don't quite know what to do with this. Thoughts? At a glance I'd say that the first ADR / TEL element with a TYPE element shows up, but a ADR / TEL element without a TYPE (which is a bit odd) doesn't appear. If there is are multiple ADR / TEL elements with a TYPE then the 'first' (arbitrarily) appears [you get one of them]. -- Adam Tauno Williams <awill...@whitemice.org> LPIC-1, Novell CLA <http://www.whitemiceconsulting.com> OpenGroupware, Cyrus IMAPd, Postfix, OpenLDAP, Samba _______________________________________________ evolution-list mailing list evolution-list@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-list
