After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 543069 - CalDAV and recurring Appointments
CalDAV and recurring Appointments
Status: RESOLVED FIXED
Product: evolution-data-server
Classification: Platform
Component: Calendar
2.24.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: evolution-calendar-maintainers
Evolution QA team
evolution[caldav]
: 574000 577808 579561 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-07-15 10:11 UTC by Milan Crha
Modified: 2009-05-25 21:37 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
proposed eds patch (3.27 KB, patch)
2008-07-15 11:55 UTC, Milan Crha
none Details | Review

Description Milan Crha 2008-07-15 10:11:06 UTC
Moving this from the downstream bugzilla against Fedora 9:
http://bugzilla.redhat.com/show_bug.cgi?id=454527

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.

---------------------------------------------

I can reproduce this on actual trunk too, the edited recurring appointment is not shown in the UI, even it is received from the server. I will investigate more to see what causes this. I changed only the Location in the appointment and saved to all instances.
Comment 1 Milan Crha 2008-07-15 11:19:12 UTC
There is a sample component in the downstream bug, which has a RECURRENCE-ID field. I thought it's not so important, but now I see it is. The file backend uses some code to make from it a master object, thus I will make it to caldav backend too. I thought I did this before in other bug, somehow.
Comment 2 Milan Crha 2008-07-15 11:55:23 UTC
Created attachment 114594 [details] [review]
proposed eds patch

for evolution-data-server;

The code was copied from the file backend. I also noticed the CalDAV backend knows how to modify all instances only, thus returning an error in case someone wants to modify only one instance.
Comment 3 Srinivasa Ragavan 2008-07-20 13:42:11 UTC
Gicmo: Review for you :) 

Btw, I met Thomas, your mentor and had a few discussions with him.
Comment 4 Chenthill P 2009-01-12 11:39:44 UTC
Milan, can we ask the user whether he wants to modify a particular instance or all instances and then open the master event or the instance based on the input ? If this is done, I think handling the dates between instance and master event would not be necessary in the backend and would be more clean..
Comment 5 Milan Crha 2009-01-12 12:00:45 UTC
I guess you aim at bug #561312, right? I agree, we can mark this a as a duplicate, in a sense the other bug will solve this one for free.
Comment 6 Milan Crha 2009-04-27 16:28:05 UTC
Patches from bug #561312 didn't help at all here, but also the initial patch is not correct. I'm rejecting it and will try to produce a fix which will add recurrence modification support in CalDAV.
Comment 7 Milan Crha 2009-04-27 16:29:25 UTC
*** Bug 574000 has been marked as a duplicate of this bug. ***
Comment 8 Milan Crha 2009-04-27 16:31:01 UTC
*** Bug 577808 has been marked as a duplicate of this bug. ***
Comment 9 Milan Crha 2009-05-25 14:57:20 UTC
Created commit db2483e in eds master.

The fix will be included in evolution-data-server 2.27.3+.

(Also Created commit be4ca0b in evo master, to itip-formatter plugin, to search for master object, if the exact detached instance wasn't found. Partly related to this.)
Comment 10 Milan Crha 2009-05-25 21:37:41 UTC
*** Bug 579561 has been marked as a duplicate of this bug. ***