Bug 454527 - Caldav and recucurring Appointments
Caldav and recucurring Appointments
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: evolution (Show other bugs)
9
All Linux
low Severity medium
: ---
: ---
Assigned To: Matthew Barnes
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-08 17:34 EDT by Ronald Kuetemeier
Modified: 2008-07-15 06:11 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-07-15 06:11:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Bugzilla 543069 None None None Never

  None (edit)
Description Ronald Kuetemeier 2008-07-08 17:34:52 EDT
Description of problem:
The cached object uid gets messed up when an recurring appointment is edited.
Therefore the Appointment is not displayed anymore, while alarms still work.
Also the clock shows the Appointment correctly, only Evolution's display is
messed up.  The Caldav DB is updated correctly, and reflects the updated item.

Example cached object uid:

  <object
uid="20080708T152319Z-16295-500-1-2@acer.kuetemeier.com@20080708T110000">BEGIN:VEVENT
UID:20080708T152319Z-16295-500-1-2@acer.kuetemeier.com
DTSTAMP:20080708T152319Z
DTSTART;TZID=/softwarestudio.org/Tzfile/America/Denver:20080708T110000
DTEND;TZID=/softwarestudio.org/Tzfile/America/Denver:20080708T113000
TRANSP:OPAQUE
SEQUENCE:5
SUMMARY:Test 3
CLASS:PUBLIC
RECURRENCE-ID;TZID=/softwarestudio.org/Tzfile/America/Denver:
 20080708T110000
RRULE:FREQ=DAILY;COUNT=3;INTERVAL=1
X-EVOLUTION-CALDAV-HREF:20080708T153925Z.ics
X-EVOLUTION-CALDAV-ETAG:"9c27337a0739f621b4f1cf68542f9895"
BEGIN:VALARM
X-EVOLUTION-ALARM-UID:20080708T153925Z-18754-500-1-3@acer.kuetemeier.com
DESCRIPTION:Test 3
ACTION:DISPLAY
TRIGGER;VALUE=DURATION;RELATED=START:-PT15M
END:VALARM
END:VEVENT
</object>
Comment 1 Milan Crha 2008-07-14 10:17:07 EDT
What kind of update did you do? Aka which data field did you change? Did you do
that update for all instances or only to one instance? Also, you do not see all
appointments derived from this item or just this one? Why do you think it's
because of messed up UID?

I see this object is only one instance, not a master object (the initial object,
where isn't stored the RECURRENCE-ID), so probably only to one instance? In that
case, the event is divided into two, one master object with an exception and the
detached instance, showed in the date of the change.
Comment 2 Ronald Kuetemeier 2008-07-14 10:33:43 EDT
Doesn't matter which field you update. 
I changed all instances, was playing with it. Also doesn't seem to matter.
All appointments will disappear. 
UID seems possible because the calendar shows the appointment, and the alarms
still happen, was just a guess on what is different from everything else.
Don't know anything about the master object, but if I do an SQL search in the
CalDav DB is shows 2 or more objects (mostly identical), but I think they are
not in the cache file there seems to be only one.
Comment 3 Milan Crha 2008-07-15 06:11:58 EDT
I can reproduce this bug. I will move it upstream, add yourself to the upstream
bug [1] for further information. Thanks for reporting this.

[1] http://bugzilla.gnome.org/show_bug.cgi?id=543069

Note You need to log in before you can comment on or make changes to this bug.