Tickets :: [#14510] Lightning 4.7.4 can not update Events

6.0.0-git

2019-03-18

Summary	Lightning 4.7.4 can not update Events
Queue	Kronolith
Queue Version	4.2.18
Type	Bug
State	Not A Bug
Priority	1. Low
Owners
Requester	helms (at) uni-bremen (dot) de
Created	2016-11-11 (857 days ago)
Due
Updated	2017-10-20 (514 days ago)
Assigned	2016-11-11 (857 days ago)
Resolved	2016-11-14 (854 days ago)
Milestone
Patch	No

2017-10-20 20:33:48	Git Commit	Comment #11	Reply to this comment
Changes have been made in Git (FRAMEWORK_5_2): commit 8091ccebef09a69aac021aee95c4405ec98435d7 Author: Jan Schneider <jan@horde.org> Date: Mon, 14 Nov 2016 14:52:20 +0100 Note that History is required for synchronization. Helps with ~~bug #14510~~ and similar. M config/conf.xml https://github.com/horde/base/commit/8091ccebef09a69aac021aee95c4405ec98435d7

2016-11-15 17:09:06	Git Commit	Comment #10	Reply to this comment
Changes have been made in Git (master): commit b09e897db3ed19cea88e8d9755429bbcc4b78109 Author: Jan Schneider <jan@horde.org> Date: Mon Nov 14 14:50:31 2016 +0100 Note that History is required for synchronization. Helps with ~~bug #14510~~ and similar. horde/config/conf.xml \| 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) http://github.com/horde/horde/commit/b09e897db3ed19cea88e8d9755429bbcc4b78109

2016-11-14 13:52:43	Jan Schneider	State ⇒ Not A Bug

2016-11-14 13:52:32	Git Commit	Comment #9	Reply to this comment
Changes have been made in Git (FRAMEWORK_5_2): commit 9b461bb7bd03052954d5d7c4db6c28f44495645a Author: Jan Schneider <jan@horde.org> Date: Mon Nov 14 14:50:31 2016 +0100 Note that History is required for synchronization. Helps with ~~bug #14510~~ and similar. horde/config/conf.xml \| 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) http://github.com/horde/horde/commit/9b461bb7bd03052954d5d7c4db6c28f44495645a

2016-11-14 13:01:23	helms (at) uni-bremen (dot) de	Comment #8	Reply to this comment
Not spooky at all. Any synchronization needs history information, otherwise you don't know which elements changed. Or are you saying that you had a history backend configured, but a different one than mysql? There was no other backend. The backend was disabled because there was no reason to enable or disable it. At the moment, there are a thunderbird client that can not disable a reminder of a event. If the girl try it in the website horde write 'missing domain'. If she fill in the default e-mail address she can disable the event reminder in the website.

2016-11-14 10:53:23	Jan Schneider	Comment #7	Reply to this comment
Not spooky at all. Any synchronization needs history information, otherwise you don't know which elements changed. Or are you saying that you had a history backend configured, but a different one than mysql?

2016-11-14 07:51:12	helms (at) uni-bremen (dot) de	Comment #6	Reply to this comment
Any chance that you don't have a history backend configured? This is spooky. If I enable the history with a mysql backend it works. --- \| history_id \| object_uid \| history_action \| history_ts \| history_desc \| history_who \| history_extra \| history_modseq \| \| 2887572 \| kronolith:FrK_wnAkETdEIeznjBkJFFe:8fcc8af9-b7d6-45af-8f17-f7bbf827956a \| modify \| 1479109672 \| NULL \| testuser \| a:2:{s:3:"new";a:2:{s:11:"event_start";s:19:"2016-11-10 14:00:00";s:9:"event_end";s:19:"2016-11-10 15:00:00";}s:3:"old";a:2:{s:11:"event_start";N;s:9:"event_end";N;}} \| 602487 \|

2016-11-11 14:04:37	Jan Schneider	Comment #5	Reply to this comment
Any chance that you don't have a history backend configured?

2016-11-11 13:58:46	Jan Schneider	Comment #4	Reply to this comment
The server doesn't actually send SEQUENCE back, though Lightning didn't send one in this example either. And the X-MOZ-GENERATION is a proprietary attribute, so Lightning cannot rely on it either. Another difference that I discovered in these two examples is the following though: CalDAV: skipping item with unmodified etag : "dc453d85b5035f3559cb6bf085b7f488" Looks like we don't send an updated etag value for the changed event for some reason. At least that's what the client thinks.

2016-11-11 12:47:20	helms (at) uni-bremen (dot) de	Comment #3	Reply to this comment
Hello! First of all thank you for the quick reply. Such reaction times are really rare. We have been using the horde products since Horde-3. The documentation is very good and the functionality is exceptional. The following functions fail * Change appointments The wire trace that you posted belows shows that the event title is actually changed though. Horde receives and stores the update but thunderbird do not receives or accepts an confirmation for the update. Seamonkey can handle the calendar without any problems. What makes you think this is a Horde bug then? FWIW, I can update events with Lightning 4.7.4 just fine. I have made a fresh installation according to the instructions and the same error occurs. I created a radical server and the error did not occur. The radical server differs only minimally in the transmitted and received data. The server sends X-MOZ-GENERATION SEQUENCE in its responses. Because Kronolith is not an iCalendar storage. It's a calendar server that converts to and from iCalendar instead. Ok. Thunderbird shows the old values. Sounds like a Thunderbird problem to me then, unless proven otherwise. A radicale excample. There is an event. The description is changed in "1.Termin". Here's what happens: --- CalDAV: send: BEGIN:VCALENDAR PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN VERSION:2.0 BEGIN:VTIMEZONE TZID:Europe/Berlin BEGIN:DAYLIGHT TZOFFSETFROM:+0100 TZOFFSETTO:+0200 TZNAME:CEST DTSTART:19700329T020000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3 END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:+0200 TZOFFSETTO:+0100 TZNAME:CET DTSTART:19701025T030000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 END:STANDARD END:VTIMEZONE BEGIN:VEVENT CREATED:20161111T123623Z LAST-MODIFIED:20161111T123656Z DTSTAMP:20161111T123656Z UID:8ec3f99f-3456-4a57-a349-b92441452fe9 SUMMARY:1.Termin DTSTART;TZID=Europe/Berlin:20161110T140000 DTEND;TZID=Europe/Berlin:20161110T150000 TRANSP:OPAQUE X-RADICALE-NAME:8ec3f99f-3456-4a57-a349-b92441452fe9.ics X-MOZ-GENERATION:1 END:VEVENT END:VCALENDAR --- CalDAV: recv: --- CalDAV: Item modified successfully on Schneider --- CalDAV: send(http://radicale.zfn.uni-bremen.de/testuser/schneider/): <?xml version="1.0" encoding="UTF-8"?> <C:calendar-multiget xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav"><D:prop><D:getetag/><C:calendar-data/></D:prop><D:href>/testuser/schneider/8ec3f99f-3456-4a57-a349-b92441452fe9.ics</D:href></C:calendar-multiget> --- CalDAV: recv: <multistatus> <response> <href>/testuser/schneider/8ec3f99f-3456-4a57-a349-b92441452fe9.ics</href> <propstat> <prop> <getetag>"8a9fdc121281338c9ebafa657a078d9e"</getetag> <C:calendar-data>BEGIN:VCALENDAR PRODID:-//Radicale//NONSGML Radicale Server//EN VERSION:2.0 BEGIN:VEVENT CREATED:20161111T123623Z LAST-MODIFIED:20161111T123656Z DTSTAMP:20161111T123656Z UID:8ec3f99f-3456-4a57-a349-b92441452fe9 SUMMARY:1.Termin DTSTART;TZID=Europe/Berlin:20161110T140000 DTEND;TZID=Europe/Berlin:20161110T150000 TRANSP:OPAQUE X-RADICALE-NAME:8ec3f99f-3456-4a57-a349-b92441452fe9.ics X-MOZ-GENERATION:1 END:VEVENT BEGIN:VTIMEZONE TZID:Europe/Berlin BEGIN:DAYLIGHT TZOFFSETFROM:+0100 TZOFFSETTO:+0200 TZNAME:CEST DTSTART:19700329T020000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3 X-RADICALE-NAME:Europe/Berlin END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:+0200 TZOFFSETTO:+0100 TZNAME:CET DTSTART:19701025T030000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 X-RADICALE-NAME:Europe/Berlin END:STANDARD X-RADICALE-NAME:Europe/Berlin END:VTIMEZONE END:VCALENDAR </C:calendar-data> </prop> <status>HTTP/1.1 200 OK</status> </propstat> </response> </multistatus> --- aChangeLogListener=undefined calendarURI=http://radicale.zfn.uni-bremen.de/testuser/schneider/ iscached=false this.mQueuedQueries.length=0 --- Thunderbird displays '1.Termin'

2016-11-11 11:34:34	Jan Schneider	Comment #2 State ⇒ Feedback Priority ⇒ 1. Low	Reply to this comment
The following functions fail * Change appointments The wire trace that you posted belows shows that the event title is actually changed though. * Delete notifications The error occurs in version 4 of Lightning. Seamonkey can handle the calendar without any problems. What makes you think this is a Horde bug then? FWIW, I can update events with Lightning 4.7.4 just fine. [Show Quoted Text - 15 lines][Hide Quoted Text] Example: I change the Summary in '1' an save the event. CalDAV: recv: <d:multistatus><d:response><d:href>/horde3/rpc/calendars/testuser/calendar~FrK_wnAkETdEIeznjBkJFFe/8fcc8af9-b7d6-45af-8f17-f7bbf827956a.ics</d:href><d:propstat><d:prop><cal:calendar-data>BEGIN:VCALENDAR VERSION:2.0 X-WR-CALNAME:Kalender von testuser PRODID:-//The Horde Project//Horde iCalendar Library//EN BEGIN:VEVENT DTSTART;TZID=Europe/Berlin:20161110T130000 DTEND;TZID=Europe/Berlin:20161110T140000 DTSTAMP:20161111T090339Z UID:8fcc8af9-b7d6-45af-8f17-f7bbf827956a SUMMARY:1 The SUMMARY has successfully changed. Why delete Horde 'X-MOZ-GENERATION:1' and 'SEQUENCE:1' ? Because Kronolith is not an iCalendar storage. It's a calendar server that converts to and from iCalendar instead. Thunderbird shows the old values. Sounds like a Thunderbird problem to me then, unless proven otherwise.

2016-11-11 09:15:09	helms (at) uni-bremen (dot) de	Comment #1 Type ⇒ Bug State ⇒ Unconfirmed Priority ⇒ 3. High Summary ⇒ Lightning 4.7.4 can not update Events Due ⇒ 2016-11-11 Queue ⇒ Kronolith Milestone ⇒ Patch ⇒ No	Reply to this comment
Hello! I'm trying to edit my calendar with Lighning. The server use horde 5.2.16, kronolith 4.2.18, SabreDAV 1.8.10-stable, PHP 5.6.27, apache 2.4.10 The Horde server has a Caldav interface. The following functions work: * I can create appointments. * I can delete appointments. The following functions fail * Change appointments * Delete notifications The error occurs in version 4 of Lightning. Seamonkey can handle the calendar without any problems. Example: I change the Summary in '1' an save the event. --- CalDAV: send: BEGIN:VCALENDAR PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN VERSION:2.0 BEGIN:VTIMEZONE TZID:Europe/Berlin BEGIN:DAYLIGHT TZOFFSETFROM:+0100 TZOFFSETTO:+0200 TZNAME:CEST DTSTART:19700329T020000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3 END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:+0200 TZOFFSETTO:+0100 TZNAME:CET DTSTART:19701025T030000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 END:STANDARD END:VTIMEZONE BEGIN:VEVENT LAST-MODIFIED:20161111T090339Z DTSTAMP:20161111T090339Z UID:8fcc8af9-b7d6-45af-8f17-f7bbf827956a SUMMARY:1 STATUS:CONFIRMED DTSTART;TZID=Europe/Berlin:20161110T130000 DTEND;TZID=Europe/Berlin:20161110T140000 CLASS:PUBLIC TRANSP:OPAQUE SEQUENCE:1 X-MOZ-GENERATION:1 END:VEVENT END:VCALENDAR --- CalDAV: recv: --- CalDAV: Item modified successfully on testuser --- CalDAV: send(http://webmail-2.zfn.uni-bremen.de/horde3/rpc/calendars/testuser/calendar~FrK_wnAkETdEIeznjBkJFFe/): <?xml version="1.0" encoding="UTF-8"?> <C:calendar-multiget xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav"><D:prop><D:getetag/><C:calendar-data/></D:prop><D:href>/horde3/rpc/calendars/testuser/calendar~FrK_wnAkETdEIeznjBkJFFe/8fcc8af9-b7d6-45af-8f17-f7bbf827956a.ics</D:href></C:calendar-multiget> --- CalDAV: skipping item with unmodified etag : "dc453d85b5035f3559cb6bf085b7f488" --- CalDAV: recv: <d:multistatus><d:response><d:href>/horde3/rpc/calendars/testuser/calendar~FrK_wnAkETdEIeznjBkJFFe/8fcc8af9-b7d6-45af-8f17-f7bbf827956a.ics</d:href><d:propstat><d:prop><cal:calendar-data>BEGIN:VCALENDAR VERSION:2.0 X-WR-CALNAME:Kalender von testuser PRODID:-//The Horde Project//Horde iCalendar Library//EN BEGIN:VEVENT DTSTART;TZID=Europe/Berlin:20161110T130000 DTEND;TZID=Europe/Berlin:20161110T140000 DTSTAMP:20161111T090339Z UID:8fcc8af9-b7d6-45af-8f17-f7bbf827956a SUMMARY:1 CLASS:PUBLIC STATUS:CONFIRMED TRANSP:OPAQUE END:VEVENT BEGIN:VTIMEZONE TZID:Europe/Berlin BEGIN:DAYLIGHT TZOFFSETFROM:+0100 TZOFFSETTO:+0200 DTSTART:19160430T230000 TZNAME:CEST END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:+0200 TZOFFSETTO:+0100 DTSTART:19161001T010000 TZNAME:CE-T END:STANDARD BEGIN:DAYLIGHT TZOFFSETFROM:+0100 TZOFFSETTO:+0200 DTSTART:19170416T020000 RRULE:FREQ=YEARLY;BYMONTH=4;BYMONTHDAY=15,16,17,18,19,20,21;BYDAY=1MO;UNTIL =19180421T000000Z TZNAME:CEST END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:+0200 TZOFFSETTO:+0100 DTSTART:19170917T020000 RRULE:FREQ=YEARLY;BYMONTH=9;BYMONTHDAY=15,16,17,18,19,20,21;BYDAY=1MO;UNTIL =19180915T000000Z TZNAME:CE-T END:STANDARD BEGIN:DAYLIGHT TZOFFSETFROM:+0100 TZOFFSETTO:+0200 DTSTART:19400401T020000 TZNAME:CEST END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:+0200 TZOFFSETTO:+0100 DTSTART:19421102T020000 TZNAME:CE-T END:STANDARD BEGIN:DAYLIGHT TZOFFSETFROM:+0100 TZOFFSETTO:+0200 DTSTART:19430329T020000 TZNAME:CEST END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:+0200 TZOFFSETTO:+0100 DTSTART:19431004T020000 TZNAME:CE-T END:STANDARD BEGIN:DAYLIGHT TZOFFSETFROM:+0100 TZOFFSETTO:+0200 DTSTART:19440403T020000 RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=1MO;UNTIL=19450401T010000Z TZNAME:CEST END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:+0200 TZOFFSETTO:+0100 DTSTART:19441002T020000 TZNAME:CE-T END:STANDARD BEGIN:STANDARD TZOFFSETFROM:+0100 TZOFFSETTO:+0100 DTSTART:19450916T020000 TZNAME:CE-T END:STANDARD BEGIN:DAYLIGHT TZOFFSETFROM:+0100 TZOFFSETTO:+0300 DTSTART:19450524T020000 TZNAME:CEMT END:DAYLIGHT BEGIN:DAYLIGHT TZOFFSETFROM:+0300 TZOFFSETTO:+0200 DTSTART:19450924T030000 TZNAME:CEST END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:+0200 TZOFFSETTO:+0100 DTSTART:19451118T020000 TZNAME:CE-T END:STANDARD BEGIN:DAYLIGHT TZOFFSETFROM:+0100 TZOFFSETTO:+0200 DTSTART:19460414T020000 TZNAME:CEST END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:+0200 TZOFFSETTO:+0100 DTSTART:19461007T020000 TZNAME:CE-T END:STANDARD BEGIN:STANDARD TZOFFSETFROM:+0100 TZOFFSETTO:+0100 DTSTART:19471005T020000 RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=1SU;UNTIL=19491002T010000Z TZNAME:CE-T END:STANDARD BEGIN:DAYLIGHT TZOFFSETFROM:+0100 TZOFFSETTO:+0200 DTSTART:19470406T030000 TZNAME:CEST END:DAYLIGHT BEGIN:DAYLIGHT TZOFFSETFROM:+0200 TZOFFSETTO:+0300 DTSTART:19470511T020000 TZNAME:CEMT END:DAYLIGHT BEGIN:DAYLIGHT TZOFFSETFROM:+0300 TZOFFSETTO:+0200 DTSTART:19470629T030000 TZNAME:CEST END:DAYLIGHT BEGIN:DAYLIGHT TZOFFSETFROM:+0200 TZOFFSETTO:+0200 DTSTART:19480418T020000 TZNAME:CEST END:DAYLIGHT BEGIN:DAYLIGHT TZOFFSETFROM:+0200 TZOFFSETTO:+0200 DTSTART:19490410T020000 TZNAME:CEST END:DAYLIGHT BEGIN:DAYLIGHT TZOFFSETFROM:+0100 TZOFFSETTO:+0200 DTSTART:19800406T010000 RRULE:FREQ=YEARLY;BYMONTH=4;BYDAY=1SU;UNTIL=19800406T000000Z TZNAME:CEST END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:+0200 TZOFFSETTO:+0100 DTSTART:19800928T010000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=9;UNTIL=19950923T230000Z TZNAME:CE-T END:STANDARD BEGIN:DAYLIGHT TZOFFSETFROM:+0100 TZOFFSETTO:+0200 DTSTART:19810329T010000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3 TZNAME:CEST END:DAYLIGHT BEGIN:STANDARD TZOFFSETFROM:+0200 TZOFFSETTO:+0100 DTSTART:19961027T010000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 TZNAME:CE-T END:STANDARD END:VTIMEZONE END:VCALENDAR </cal:calendar-data><d:getetag>"dc453d85b5035f3559cb6bf085b7f488"</d:getetag></d:prop><d:status>HTTP/1.1 200 OK</d:status></d:propstat></d:response></d:multistatus> --- aChangeLogListener=undefined calendarURI=http://webmail-2.zfn.uni-bremen.de/horde3/rpc/calendars/testuser/calendar~FrK_wnAkETdEIeznjBkJFFe/ iscached=false this.mQueuedQueries.length=0 --- Why delete Horde 'X-MOZ-GENERATION:1' and 'SEQUENCE:1' ? Thunderbird shows the old values. Webmail shows the new values. With best regards Arnold