Re: [Evolution] Regenerating addressbook.db

[Adam Tauno Williams <awilliam whitemice org>]

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 <awilliam whitemice org> LPIC-1, Novell CLA
<http://www.whitemiceconsulting.com>
OpenGroupware, Cyrus IMAPd, Postfix, OpenLDAP, Samba