|Summary:||Caldav and recucurring Appointments|
|Product:||[Fedora] Fedora||Reporter:||Ronald Kuetemeier <bugzilla>|
|Component:||evolution||Assignee:||Matthew Barnes <mbarnes>|
|Status:||CLOSED UPSTREAM||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-07-15 10:11:58 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
Description Ronald Kuetemeier 2008-07-08 21:34:52 UTC
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="20080708T152319Zfirstname.lastname@example.org@20080708T110000">BEGIN:VEVENT UID:20080708T152319Zemail@example.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:20080708T153925Zfirstname.lastname@example.org DESCRIPTION:Test 3 ACTION:DISPLAY TRIGGER;VALUE=DURATION;RELATED=START:-PT15M END:VALARM END:VEVENT </object>
Comment 1 Milan Crha 2008-07-14 14:17:07 UTC
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 14:33:43 UTC
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.