Hallo, ich möchte einmal auf einen nachvollziehbaren Fehler in 57_Calendar.pm in Verbindung mit Baikal aufmerksam machen.
Problem:
Ein bereits bekannter Termin wird nicht mit dem nächsten Abruf modifiziert wenn dieser sich auf dem Server(Baikal) verändert hat.
Ausgangslage:
Nachvollziehbar ist dieser Fehler mit Baikal(0.5.0) und 57_Calendar.pm(16742 2018-05-15 19:20:16Z) und folgendem Define:
define calendar Calendar ical url http://user:password@127.0.0.1/baikal/cal.php/calendars/user/calendarname?export 43200
Für alle die diesen Fehler nachvollziehen möchten habe ich zwei Abfragen vom Server angehangen, in welcher sich ausschließlich die Uhrzeiten verändert haben. Dazu habe ich noch das diff erstellt, welches schnell die Änderung zeigt.
Fehlerbeschreibung:
Ich nutze einen Arbeitsplan, welcher über mehrere Geräte (Smartphone/Laptop/Fhem) automatisiert durch einen Server syncron gehalten wird. Der Plan ist oftmals bereits 14Tage vorher bekannt und wird demzufolge auch zeitnah eingepflegt. Selten ändert sich jedoch die Arbeitszeit, welche durch Anpassung im Kalender gepflegt wird.
Ein vorhandener Eintrag im Modul wird nicht als verändert erkannt wenn dieser modifiziert wurde. Modifiziert wurde von mir die Start und Endzeit. Eine erweiterte Logausgabe zeigt, dass der Eintrag auch nach der Modifikation als bekannt erkannt wurde.
1 records processed, 0 new, 1 known, 0 modified, 0 changed.
Wird der Eintrag in Fhem gelöscht, wird dieser Termin richtig als neu erkannt und somit auch richtig in das System aufgenommen:
1 records processed, 1 new, 0 known, 0 modified, 0 changed.
Vermutung:
Da das 75_Calendar.pm Modul das einzige Gerät ist, welches die Modifikation nicht erkennt - Smortphone/Laptop erkennen die Modifikation richtig - und die Neueinrichtung des Termins funktioniert, schließe ich einen Übertragungsfehler aus und vermute einen Fehler in der Routine zur Erkennung von modifizierten Terminen.
Hallo,
herzlichen Dank für die exakte Problembeschreibung.
Das Kalendermodul wertet das Attribut LAST-MODIFIED aus. Baikal setzt bei Änderungen DTSTAMP neu.
Die Vorgehensweise von Baikal entspricht nicht dem RFC (https://tools.ietf.org/html/rfc5545): DTSTAMP ist der Zeitpunkt, zu dem der Termin erstellt wurde, LAST-MODIFIED der Zeitpunkt der letzten Änderung.
Damit diese falsche Vorgehensweise von Baikal erkannt wird, habe ich im Modul die Prüfung auf geänderte Einträge entsprechend erweitert. Bitte finde das erweiterte Modul anbei mit der Bitte um Test.
Viele Grüße
Boris
Danke für die schnellen und vor allem ausführlichen Darstellungen zum Problem.
Das Problem scheint(ich weiß es bereits) dann wohl doch nicht Baikal zu sein.
- Ich habe mal das Git zu Sabre gesichtet (https://github.com/sabre-io/dav (https://github.com/sabre-io/dav)) und nach LAST-MODIFIED ausschau gehalten. Die haben das vor ewig langer Zeit schon implementiert gehabt.
- Jetzt habe ich die Clients im Verdacht die Einträge falsch syncronisieren könnten.
- Linux mit evolution macht alles richtig und setzt ein LAST-MODIFIED bereits zur Erstellung. Eine Änderung bewirkt dann auch:
1 records processed, 0 new, 0 known, 0 modified, 1 changed
- die Clients auf Android machen aber richtig etwas falsch:
- Sie ziehen einen Kalendereintrag hinein, der ein LAST-MODIFIED aufweist, nur wenn der Kalender erstellt wird.
- Sie sorgen bei einer Änderung dafür, dass diese Eigenschaft entfernt wird und somit auf dem Server verschwindet.
- Bei einer Aktualisierung werden eventuelle Kalendereinträge mit dieser Eigenschaft scheinbar ignoriert.
- Der Client, welcher die Probleme verursacht ist aus dem PlayStore und nennt sich "iCal Import/Export CalDAV Pro"
- Eine Lösung ist eine Einstellung im Kalender von iCal mit den Namen "CTag nicht merken" zu aktivieren. Was diese im Ganzen bewirkt kann ich derzeit noch nicht sagen, Anfrage Läuft an den Entwickler, aber damit kommen schonmal die Termine auf Android. Verändert werden diese jedoch noch immer chaotisch.
Ich werde dem Fehler mal weiter auf die Spur gehen um den wirklichen Fehler zu finden und eventuell zu beheben. Die Modifizierte 57_Calendar.pm teste ich dennoch auf Kompatibilität.
Ich bin aber der Meinung, dass wir nicht wegen einen Softwarefehler woanders diesen bei uns behandeln sollten. Ob das dann wirklich ins SVN kommen sollte - ich bin der Meinung -> nein.
mit besten Grüßen zum Wochenende
Kurze Rückmeldung zum Fix.
Ich habe ein wenig hin und her getestet. Mit der erweiterten Bedingung wird eine Änderung nun auch in Fhem eingepflegt.
Was aufgefallen ist: Wenn iCal einen Termin erstmalig ändert, wird dieser als changed gelogt. Sonst wie nun implementiert als modifiziert. Für alle die darauf Wert - Events steuern oder ähnliches - legen, sollten das wissen.
Was aus meiner Anfrage zu iCal herauskommt, werde ich hier mitteilen.