GNOME Bugzilla – Bug 476640
Deleting a meeting after someone accepted invitation fails
Last modified: 2008-06-25 12:32:59 UTC
Forwarding this from a downstream bug report: http://bugzilla.redhat.com/show_bug.cgi?id=224191 I was able to reproduce this with Evolution 2.11.92. The Red Hat bug report has a screenshot. --- If i follow these steps: 1. Arrange a new meeting with someone and send him an invitation. 2. The other person receives invitation, accepts it, and send a reply. 3. I receive the reply, update my meeting status. 4. I cancel the meeting (by going to calendar monthly view, right-clicking, select "Delete") and send out a notice. On my side, the meeting is deleted. 5. The other person receives the cancel notice, and updates the calendar from the email. Then switches to Calendar view - the meeting is still there. Further, if the person tries to delete that meeting, it is deleted (at least switching back to email, the notice email says "Unable to find this meeting..."), but it still appears in Calendar, until Evolution is switched off. Further, when i switch off Evolution at this point, viewing Calendar (monthly view), on the next start, it starts in Calendar view, which is somehow changed (more windows appear), but switching back to email then to Calendar makes the Cal. view normal.
Created attachment 103142 [details] [review] proposed eds patch for evolution-data-server;
I can confirm the patch fixes the problem. I'll leave it to the calendar experts to approve it.
+ /* do not pass here the "new" object, because this was a remove of whole object */ + e_cal_backend_notify_object_removed (E_CAL_BACKEND (backend), id, old_object, NULL); You would need to pass the new object in case only an instance of a recurring meeting was canceled by checking for the presence of RID.
Chen, are you sure with this? I tested it and it works as expected. I sent myself new invitation, then delete one occurrence, and then delete all occurrences, and if I accept/update calendar in same order, then it works as expected, I have same state as when I was sending it. Do I miss something?
Bumping version to a stable release.
Milan, am not sure in which cases it might fail. It might not fail in evolution but it might fail if someone writes a new client to EDS. The object_modified would be triggered only when both old and new objects are returned back. You can check out the match_query_and_notify function at e-cal-backend.c.
Created attachment 113393 [details] [review] proposed eds patch ][ for evolution-data-server; I did as you said. I also simplified it more, so only one lookup is required here, instead of two.
This patch looks fine. Please commit the same.
Committed to trunk. Committed revision 9043.