Contributed on 10.09.2006 by Mathias Weyland, who also graciously provided access to a server for testing for a while. Not currently tested.

SyncEvolution can handle synchronization with eGroupware (eGW), starting with 0.4-pre2 plus one patch, which was included in 0.4.

Make sure eGW fits the needs for correct operation with syncML, in particular php5 and Pear::Log. See here for information about requirements and settings.

The SyncEvolution setup is rather straightforward. Although the SyncML code of eGW is based on horde (see above), there's no need to restrict authentication to auth-basic.

Set syncURL to http://<host>/<egw-base>/rpc.php. Set "type = text/calendar" and "uri = ./calendar" for the calendar and "type = text/x-vcard" and "uri = ./contacts", respectively for the address book.

Warning: "uri = ./calendar" apparently is the official uri, but several users reported that with that setting events created in eGW were not copied into Evolution while "uri = calendar" worked alright. Until this is clarified, the recommendation is to use "uri = calendar".

All in all, synchronization is working well, but I'd like to mention some things I noticed not to work:

  • Recurring events don't stop at a final date in eGW, even when this final date has been set in evolution. "A known issue of old Evolution versions." -- Patrick
  • Recurrence exceptions are not respected. "eGW seems to rely on storing the remaining instances of an event, but does not include this information in the data it sends to SyncEvolution. On the other hand, SyncEvolution also does not yet support this either. Exceptions defined in Evolution's dialog are stored as simple properties and are sent to the server, but eGW does not seem to use that information."
  • New appointments in eGW are not sync'ed to evolutions. But updates are. "Could not reproduce. If it still occurs, please submit a bug report."
  • With SyncEvolution 0.6, Ioannis Ioannou had a problem with lost or messed up telephones. Part of the problem was in SyncEvolution (it did not correctly detect types as sent by eGW, fixed in 0.7), part of the problem was in eGW (it does not handle the vCards sent by SyncEvolution correctly). Ioannis found out that eGW has hard-coded mappings for incoming data, which might have to be adapted on a case-by-case basis for clients. He submitted a patch (thanks!) which adds a SyncEvolution mapping to eGW. Hopefully this problem will be fixed. The original version of his patch changes in egroupware/addressbook/inc and was tested on 1.4.001, 1.4.002, and the trunk of 2007-09-25th.
  • If communication with eGW stops with a Server Failure: server returned error code -1 error, then the reason is most likely a parser problem in eGW. Some information about this can also be found in the same discussion thread.