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