Re: [Evolution] Regenerating addressbook.db

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
OpenGroupware, Cyrus IMAPd, Postfix, OpenLDAP, Samba

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]