On Wed, 2011-11-23 at 12:41 +0200, Dmitry Nezhevenko wrote:
> I've found that syncevolution forgets about second "X-Jabber" record while
> getting contacts from Evolution.

This shouldn't happen. The internal field list supports more than one
X-JABBER entry. I'm not entirely happy with having to define one field
for each kind of chat handle, but that is irrelevant for your problem:

      <!-- chat handles: should be turned into one array, like WEB and 
CALURI/FBURL -->
      <field name="AIM_HANDLE"        array="yes" type="string" 
compare="conflict"/>
      <field name="AIM_SLOT"          array="yes" type="string" 
compare="conflict"/>
...
      <field name="JABBER_HANDLE"        array="yes" type="string" 
compare="conflict"/>
      <field name="JABBER_SLOT"          array="yes" type="string" 
compare="conflict"/>

Conversion to and from vCard is defined here:

        <property name="X-JABBER" suppressempty="yes" rule="KDE"/>
        <property name="X-JABBER" suppressempty="yes" rule="other">
          <value field="JABBER_HANDLE"/>
          <parameter name="X-EVOLUTION-UI-SLOT" positional="no" show="no">
            <value field="JABBER_SLOT"/>
          </parameter>
        </property>
        <property name="X-messaging/xmpp-All" suppressempty="yes" show="no" 
rule="KDE">
          <value field="JABBER_HANDLE"/>
        </property>

It's done differently for Evolution/SyncML peers and KDE.

Hmm, it looks like there's a missing
   <position field="JABBER_HANDLE" repeat="array" increment="1" minshow="0"/>
in the conversion rule.

I'll check...

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.


_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution

Reply via email to