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

[noreply at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/13113
------------------------------------------------------------------------------
  Ticket             | 13113
  Created By         | skhorde at smail.inf.fh-bonn-rhein-sieg.de
  Summary            | CalDAV/etag won't change after 2nd change in Kronolith
  Queue              | Kronolith
  Version            | 4.1.5
  Type               | Bug
  State              | Unconfirmed
  Priority           | 2. Medium
  Milestone          |
  Patch              | 1
  Owners             |
------------------------------------------------------------------------------


skhorde at smail.inf.fh-bonn-rhein-sieg.de (2014-04-14 09:05) wrote:

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



skhorde at smail.inf.fh-bonn-rhein-sieg.de (2014-04-14 09:05) uploaded:  
kronolith_loadHistory_youngest-modified.diff.bz2

http://bugs.horde.org/h/services/download/?app=whups&actionID=download_file&file=kronolith_loadHistory_youngest-modified.diff.bz2&ticket=13113&fn=%2Fkronolith_loadHistory_youngest-modified.diff.bz2