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

noreply at bugs.horde.org noreply at bugs.horde.org
Mon Apr 14 09:05:40 UTC 2014


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: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/  

<calendar-query xmlns="urn:ietf:params:xml:ns:caldav">
  <prop xmlns="DAV:">
   <getetag xmlns="DAV:"/>
   <resourcetype xmlns="DAV:"/>
  <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"/>


In Kronolith_Event::loadHistory() the modified entries are in that order:
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:  


More information about the bugs mailing list