Tickets :: Comment on [#13113] CalDAV/etag won't change after 2nd change in Kronolith

* Your Email Address
* Spam protection	Enter the letters below: . ..__..___.. . . \|\ \|\| \| _/ \| \| \| \| \\|\|__\./__.\|___\|/\\|
Comment	> I'm using: > > kronolith 4.1.5 stable > horde 5.1.6 stable > Horde_Dav 1.0.4 stable > > PEAR does not list any outstanding upgrades. > > If I delete the user data of user "user", login, create a new event > and add the standard calendar to KDE Akonadi via CalDAV, that event > is sync'ed to KDE. Then I change the start time in Kronolith, the > change is sync'ed to KDE again. Then I change one or more times again > in the GUI only, those changes are not sync'ed to KDE. > > If I change the event in KDE's Korganiser, the change is sync'ed to > Kronolith, then I can change the event in the GUI one time again in > order to sync it back to KDE. > > The horde_histories table contains entries of change of the GUI, e.g.: > > 67138 \| > kronolith:lRKXIP8i9MAv6KDdx3OFew1:20140414091444.DpToeX4M_xh0ohIpZIDZpQ2@... > \| modify \| ... \| a:2:{s:3:"new";a:10:{s ... > > I sniffed the CalDAV connection, in the 207 Multi-Status reponses of > the REPORT requests, I get: > > <d:response> > > <d:href>/horde/rpc.php/calendars/user/calendar:lRKXIP8i9MAv6KDdx3OFew1/HOu4xpua-p9SaC_JViE0Iw1.ics</d:href> > <d:propstat><d:prop><d:getetag>"abb796829cd0403ee6c3f0a25270ad30"</d:getetag> > <d:resourcetype/></d:prop> > <d:status>HTTP/1.1 200 OK</d:status></d:propstat></d:response> > > The etag does not change beginning with the 2nd change of an event in > Kronolith, no matter how often I change the event in Kronolith or try > to re-sync the calendar from KDE. Because I understand section > "Finding out if anything changed" of > http://sabre.io/dav/building-a-caldav-client/ so, that the client may > use the etag to find changes, the KDE does not request the event > again, because the etag stays the same as the previous request. > > ===== > > KDE Akonadi uses this REPORT request: > > REPORT > /horde/rpc.php/calendars/user/calendar:lRKXIP8i9MAv6KDdx3OFew1/ > HTTP/1.1\r\n > > <calendar-query xmlns="urn:ietf:params:xml:ns:caldav"> > <prop xmlns="DAV:"> > <getetag xmlns="DAV:"/> > <resourcetype xmlns="DAV:"/> > </prop> > <filter xmlns="urn:ietf:params:xml:ns:caldav"> > <comp-filter xmlns="urn:ietf:params:xml:ns:caldav" name="VCALENDAR"> > <comp-filter xmlns="urn:ietf:params:xml:ns:caldav" name="VEVENT"/> > </comp-filter> > </filter> > </calendar-query> > > ==== > > In Kronolith_Event::loadHistory() the modified entries are in that order: > loadHistory() > loadHistory(modified)=1397465499 who=user > loadHistory(modified)=1397464675 who=user > loadHistory(modified)=1397460856 who=user > loadHistory(modified)=1397460722 who=user > loadHistory(modified)=1397459781 who=user > loadHistory(modified)=1397459749 who=user > loadHistory(modified)=1397459728 who=user > > The last one wins, which is the one with the smallest / eldest > timestamp. Because of this the etag remains unchanged and KDE does > not queries the event data. Attached patch compares the timestamps of > all items returned and evaluates the highest / youngest timestamp > only. This change fixes my problem.
Attachment
Watch this ticket

Saved Queries