Problem mit caldav

Achim_Konigs 2013-12-03 23:07:55 UTC #1

Hallo,

ich bastel immer noch an einem caldav connector für webOS (und bald open webOS).

Soweit klappt das auch ganz gut. Heute sind mir allerdings ein paar Termine abhanden gekommen. Nach langem Suchen in den Logs (auf dem Gerät und die Server logs) denke ich, dass ich eine Vermutung hab, wo der Fehler liegt…

Und zwar hat das Gerät einen Termin hochgeladen, also mit PUT uri und “If-None-Match: *” im Header um nicht was anderes zu überschreiben. Das hat soweit geklappt. Dann hat sich auf dem Gerät nochmal was geändert (meinte es zumindest, bin nicht 100% sicher), also hat es ein Update des Termins an den Server geschickt. Wieder mit PUT uri und diesmal im Header "If-Match: " mit dem etag, den es vom Server zurück bekommen hat, also z.B. If-Match: “3090:0:1386058001”. Und natürlich mit dem aktualisierten Termin im Content.

Im Server log sehe ich dazu als Zusammenfassung:
*** PUT uri --> “204 No Content” took 0.277 s

Danach taucht der Termin nie wieder auf… in keinem der Logs. Ein bisschen stutzig hat mich die Erklärung von 204 hier gemacht: http://en.wikipedia.org/wiki/List_of_HTTP_status_codes

Der wird aber nicht gelöscht, oder?
Danach kommt nochmal eine etag Abfrage und da taucht der Termin dann auch nicht mehr auf => ist also tatsächlich nicht mehr in dem Ordner. Auch wenn ich mit dem Browser im Ordner gucke, ist er nicht da.

Mir ist gerade aufgefallen, dass nach dem Update im Termin ein Attendee steht. Kann es sein, dass der falsch zugeordnet wird und der Termin jetzt “im Nirvana” ist, weil er keinem existierenden User zugeordnet ist?

Hoffe auf Hilfe.

Viele Grüße
Achim

Achim_Konigs 2013-12-04 19:05:44 UTC #2

Ich hab nochmal etwas nachgeforscht. Und ich vermute, dass bei egroupware irgendwas kaputt geht, wenn der ATTENDEE wie folgt aussieht:

ATTENDEE;CN=Stephanie;EMAIL=Stephanie:MAILTO:Stephanie
ORGANIZER;CN=Stephanie:MAILTO:Stephanie

Dabei ist “Stephanie” tatsächlich der Username. Aber die E-Mail ist sehr kaputt.

Allerdings gibt es noch einen Trick bei der Sache. Wenn das ein Add ist, dann ist es ok, der Termin wird hinzugefügt. Anscheinend scheint eGroupware dann den (kaputten?) ATTENDEE Eintrag zu ignorieren. Bei einem GET taucht der jedenfalls nicht mehr im ics auf.

Wenn man dann aber hingeht und den schon im Kalendar vorhandenen Termin nochmal schickt mit der (kaputten?) ATTENDEE Zeile, dann geht er verloren. Er verschwindet dann aus der Kalenderansicht und wird dann auch vom Device gelöscht, da keine etag mehr dafür zurück geschickt wird.

Ich vermute, dass er noch irgendwo in der Datenbank rumhängt, nur jetzt keinem User mehr zugeordnet ist. Kann das sein? Kann ich das rausfinden? Gibt es eine Funktion in eGroupware, die verwaiste Einträge löscht?
Wie kann ich verhindern, dass das passiert?

Gruß
Achim

Ralf_Becker_Stylite 2013-12-04 19:16:54 UTC #3

Hi Achim,

Ich hab nochmal etwas nachgeforscht. Und ich vermute, dass bei egroupware
irgendwas kaputt geht, wenn der ATTENDEE wie folgt aussieht:

ATTENDEE;CN=Stephanie;EMAIL=Stephanie:MAILTO:Stephanie
ORGANIZER;CN=Stephanie:MAILTO:Stephanie

Dabei ist “Stephanie” tatsächlich der Username. Aber die E-Mail ist sehr
kaputt.

Allerdings gibt es noch einen Trick bei der Sache. Wenn das ein Add ist,
dann ist es ok, der Termin wird hinzugefügt. Anscheinend scheint eGroupware
dann den (kaputten?) ATTENDEE Eintrag zu ignorieren. Bei einem GET taucht
der jedenfalls nicht mehr im ics auf.

Wenn man dann aber hingeht und den schon im Kalendar vorhandenen Termin
nochmal schickt mit der (kaputten?) ATTENDEE Zeile, dann geht er verloren.
Er verschwindet dann aus der Kalenderansicht und wird dann auch vom Device
gelöscht, da keine etag mehr dafür zurück geschickt wird.

Ich vermute, dass er noch irgendwo in der Datenbank rumhängt, nur jetzt
keinem User mehr zugeordnet ist. Kann das sein? Kann ich das rausfinden?

Wenn Du noch etwas von dem Termin weißt, zB den Titel, kannst Du einfach
in der Datenbank danach suchen. Wenn Du die cal_id hast, einfach in der
egw_cal_user nach den attendees dieser cal_id schauen.

Gibt es eine Funktion in eGroupware, die verwaiste Einträge löscht?

Nein, Du kannst aber in der EGroupware den Besitzer Filter verwenden,
dann werden Dir auch Termine angezeigt die Du besitzt, an denen Du aber
nicht teilnimmst.

Wie kann ich verhindern, dass das passiert?

Schick mir die HTTP Requests, zB. aus dem CalDAV Log mit denen sich das
Problem reproduzieren lässt. Dann kann ich danach schauen.

Ralf

Gruß
Achim

–
View this message in context: http://egroupware.219119.n3.nabble.com/Problem-mit-caldav-tp3994432p3994448.html
Sent from the egroupware-german mailing list archive at Nabble.com.

Sponsored by Intel® XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

–
Ralf Becker
Director Software Development

Stylite AG

Morschheimer Strasse 15 | Tel. +49 6352 70629 0
D-67292 Kirchheimbolanden | Fax. +49 6352 70629 30

Email: rb@stylite.de

www.stylite.de | www.egroupware.org

Managing Directors: Andre Keller | Ralf Becker | Gudrun Mueller
Chairman of the supervisory board: Prof. Dr. Birger Leon Kropshofer

VAT DE214280951 | Registered HRB 31158 Kaiserslautern Germany

Sponsored by Intel® XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk

egroupware-german mailing list
egroupware-german@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/egroupware-german

Achim_Konigs 2013-12-04 21:33:19 UTC #4

Wie gesagt sind dafür zwei Requests notwendig, zuerst macht man so:

*** 5.147.14.134 2013-12-04T20:01:32+01:00
PUT /egroupware/groupdav.php/Achim/calendar/webos-1386183638698.ics HTTP/1.1
Prefer: return-minimal
Content-Type: text/calendar; charset=utf-8
Connection: keep-alive
Host: garfonso.darktech.org
If-Match: "3101:0:1386183639"
Content-Length: 441

BEGIN:VCALENDAR
VERSION:2.0
PRODID:MOBO.SYNCML.0.0.3
METHOD:PUBLISH
BEGIN:VEVENT
BEGIN:VALARM
ACTION:DISPLAY
TRIGGER;VALUE=DURATION:-PT15M
END:VALARM
ATTENDEE;CN=Achim;EMAIL=Achim:MAILTO:Achim
ORGANIZER;CN=Achim:MAILTO:Achim
DTEND:20131205T090000Z
DTSTART:20131205T080000Z
SUMMARY:verlieren Test
UID:webos-1386183638698.ics
X-FUNAMBOL-ALLDAY:0
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-AllDayEvent:FALSE
END:VEVENT
END:VCALENDAR
HTTP/1.1 204 No Content
X-Powered-By: PHP/5.4.6-1ubuntu1.4
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
X-Dav-Powered-By: EGroupware 1.8.005 CalDAV/CardDAV/GroupDAV server
Schedule-Tag: "3101:1"
ETag: "3101:1:1386183692"
X-WebDAV-Status: 204 No Content
*** PUT /Achim/calendar/webos-1386183638698.ics --> “204 No Content” took 0.134 s

und dann später ein Update:

und futsch ist der Termin.
Wenn man den zweiten Request direkt macht, geht alles gut und der “falsche” ATTENDEE wird durch den Nutzer ersetzt, dem der Kalender gehört.

Den Besitzer Filter hab ich bisher noch gar nicht gesehen gehabt… da ist der Termin dann zu sehen. Als Teilnehmer steht da Typ=“E-Mail” Teilehmer="Achim ". So kann ich das hier im Moment reproduzieren.

Gruß
Achim