[#14510] Lightning 4.7.4 can not update Events
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@uni-bremen.de
Created 2016-11-11 (1038 days ago)
Due
Updated 2017-10-20 (695 days ago)
Assigned 2016-11-11 (1038 days ago)
Resolved 2016-11-14 (1035 days ago)
Milestone
Patch No

Comments
helms@uni-bremen.de 2016-11-11 09:15:09
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

Jan Schneider <jan@horde.org> 2016-11-11 11:34:34
> 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.

>
> 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.

helms@uni-bremen.de 2016-11-11 12:47:20
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'





Jan Schneider <jan@horde.org> 2016-11-11 13:58:46
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.

Jan Schneider <jan@horde.org> 2016-11-11 14:04:37
Any chance that you don't have a history backend configured?

helms@uni-bremen.de 2016-11-14 07:51:12
> 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 |




Jan Schneider <jan@horde.org> 2016-11-14 10:53:23
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?

helms@uni-bremen.de 2016-11-14 13:01:23
> 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.


Git Commit <commits@lists.horde.org> 2016-11-14 13:52:32
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

Git Commit <commits@lists.horde.org> 2016-11-15 17:09:06
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

Git Commit <commits@lists.horde.org> 2017-10-20 20:33:48
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