6.0.0-git
2019-11-16

[#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 (at) uni-bremen (dot) de
Created 2016-11-11 (1100 days ago)
Due
Updated 2017-10-20 (757 days ago)
Assigned 2016-11-11 (1100 days ago)
Resolved 2016-11-14 (1097 days ago)
Milestone
Patch No

History
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]
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

Saved Queries