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 330992 - caldav: Modify this instance deletes all instances
caldav: Modify this instance deletes all instances
Status: RESOLVED OBSOLETE
Product: evolution
Classification: Applications
Component: Calendar
2.6.x (obsolete)
Other Linux
: Normal critical
: ---
Assigned To: evolution-calendar-maintainers
Evolution QA team
evolution[caldav]
Depends on:
Blocks: 317266
 
 
Reported: 2006-02-13 13:26 UTC by Poornima
Modified: 2013-09-10 14:04 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Poornima 2006-02-13 13:26:22 UTC 
Select a recurring meeting in caldav calendar.
Modify one of the instances duration, all instances of meeting get deleted.

Reproducible always.
Comment 1 André Klapper 2006-02-13 18:42:54 UTC 
"critical" as one can lose data.
Comment 2 André Klapper 2006-04-05 20:30:27 UTC 
poornima, this reminds me of bug 326964. do you still see this?
Comment 3 Harish Krishnaswamy 2006-08-10 12:59:31 UTC 
Set target milestone to 2.8
Comment 4 Matthew Barnes 2008-03-11 00:25:34 UTC 
Bumping version to a stable release.
Comment 5 Randy 2008-07-16 20:48:47 UTC 
I'm not sure if this is this is the same bug or not, but using Evolution 2.22, if I make a change to an instance in a recurring series in a CalDAV calendar, Evolution attempts to update the event with just the modified instance, not including the rest of the event.

In CalDAV, a recurring event + modified instances are represented as a single resource, so updating an instance requires the master VEVENT to be included as well as any other modified VEVENTs.

So what I am seeing is Evolution attempting to just send the modified VEVENT with no master VEVENT, which results in the server rejecting the request because a modification VEVENT by itself doesn't make sense without the master VEVENT.
Comment 6 Matthew Barnes 2008-11-04 12:47:23 UTC 
Works fine in Evolution 2.24.1.  Set up a recurring appointment on a CalDAV calendar, modified the duration of one of the instances (not the first), Evolution correctly handled the modified instance.

Closing as OBSOLETE since no action was taken on this particular bug.