Synthesis-Android-Client synct keine Termine mehr auf EGroupware (gefixt)

Folgendes Verhalten konnte ich in den letzten Tagen beobachten: Ein neuer Termin wird auf dem Smartphone eingetragen. Nach ein paar Stunden schaut man wieder auf den Kalender und der Termin ist verschwunden – auf Smartphone und in EGroupware.

Was war passiert?

Die erste Vermutung, daß das Verhalten mit der Synchronisierung zu tun hat hat sich zunächst bestätigt: Neuer Termin eingetragen – synchronisiert – Termin verschwunden.

Der erste Schritt war die SyncML-Verbindung mitzuloggen, indem man das Verzeichnis /tmp/sync auf dem Server erstellt und für den Webserver-User beschreibbar macht. Für jedes ausgetauschte SyncML-Paket wird dann eine Datei erzeugt, die den WBXML-Datenverkehr enthält. WBXML ist binäres XML und kann mit dem Werkzeug wbxml2xml in menschenlesbares XML konvertiert werden.

Ein SyncML-Durchlauf besteht normalerweise darin, daß der Client die Änderungen seit der letzten Synchronisierung dem Server meldet und anschließend der Server dem Client seine Änderungen mitteilt.

Aus dem Trace war nun ersichtlich, daß der Client genau eine Änderung dem Server mitteilt, nämlich den neuen Datensatz. Anschließend meldet der Server genau eine Änderung zurück, nämlich den Löschvorgang auf denselben Datensatz, den er gerade eben angelegt hat. Effekt ist, daß der eingetragene Termin auf beiden Seiten verschwindet.

Will man noch tiefer eintauchen muß man den EGroupware-internen Trace aktivieren, aus dem hervorgehen sollte, warum der gerade hinzugefügte Datensatz als gelöscht markiert wurde.

Es reicht dabei übrigens nicht, den in dem Wiki beschriebenen Konfigurationsparameter $conf['log']['priority'] auf PEAR_LOG_DEBUG zu ändern, man muß auch zusätzlich noch das Logging an sich aktivieren mit $conf['log']['enabled'] = false;

An diesem Punkt stellt sich dann heraus, daß die versprochene Datei unter /tmp nicht erscheint. Stattdessen sieht man im Apache-Fehlerlog folgende Meldung:

PHP Warning:  error_log() expects parameter 2 to be long, string given in
/usr/share/egroupware/egw-pear/Log/error_log.php on line 120

Ein kurzer manueller Eingriff an der Stelle (zweiten Parameter auf 0 setzen) führt dann zu dem gewünschten Trace. Die Meldungen erscheinen zwar nicht in einer Datei, aber immerhin im Fehlerlog des Apache.

Aus dem Trace wird ersichtlich, daß der Server tatsächlich glaubt, einen Datensatz gelöscht zu haben.

Lösung

Der Spuk verschwindet, wenn man in EGroupware in der Kalenderanzeige von dem standardmäßigen "Alle einschl. abgesagte" testweise auf "Auch Besitzer" stellt. Plötzlich sind die vormals verschwundenen Termine des Smartphones sichtbar in EGroupware.

Das ganze lässt sich zum einen auf die Option "Organisator/Teilnehmer werden auf den Server synchronisiert" im Android-Synthesis zurückführen.

Schaltet man diese Option aus, werden neu hinzugefügte Termine wieder synchronisiert. Die verschwundenen Termine gehören zwar dem aktuellen User, haben aber als Teilnehmer nicht den User selbst bzw. seine Email-Adresse eingetragen, sondern den Kalendernamen, in meinem Fall "cal1". Wird keine Info vom Smartphone an den EGroupware-SyncML-Server übertragen setzt dieser automatisch den aktuellen User als Teilnehmer ein. Den Sync-User als Teilnehmer automatisch eintragen zu lassen macht sicher mehr Sinn als "cal1". Deshalb sollte diese Option ausgeschaltet bleiben.

Zum andern kann man in den SyncML-Einstellungen in dem Abschnitt "Kalender Synchronisations Einstellungen" einen Filter definieren. Standardmäßig steht dieser auf dem verhängnisvollen "Alle inkl. abgesagte". Wird hier "Auch Besitzer" gesetzt, erscheinen auch die bereits verloren gegangenen Termine wieder auf dem Smartphone.

Man sollte sich aber trotzdem überlegen, sich selbst besser als Teilnehmer einzutragen. Leider gibt es innerhalb von EGroupware keine Möglichkeit eine Liste der Termine mit "falschem Teilnehmer" zu generieren. Auf SQL-Ebene kommt man aber mit folgender Abfrage dazu:

SELECT c.cal_id, SUBSTR(cal_uid, 1, 15) uid, cal_owner o, cal_title,   cal_user_type type,
SUBSTR(cal_user_id, 1, 25) FROM egw_cal c LEFT OUTER JOIN egw_cal_user u ON c.cal_id = u.cal_id
WHERE cal_user_type like 'e';

Das Problem war übrigens schonmal auf der Mailingliste ein Thema.