GNOME Bugzilla – Bug 643791
Duplicate events from outlook / OWA meetings
Last modified: 2011-03-07 13:40:08 UTC
Note: this is likely be related to Bug 615636, though experienced on systems with the patch for the mentioned bug already applied. You may also need the patch from Bug 643781, as we didn't see this until that bug was fixed. Symptoms: events sent from outlook and OWA clients will, when replied to in evolution, not be associated with the original events. On the sender side this means that they will either see no response from attendees, or a response associated with an event not in their calendar. For attendees, they will get a duplicate event in their calendar. an example diff between the duplicate events: --- asdf.owa.ics 2011-03-03 15:58:30.898355693 +0000 +++ asdf.dup.ics 2011-03-03 15:58:37.087305699 +0000 @@ -21,16 +21,15 @@ END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT -UID:69ED860000000001 -DTSTAMP:20110303T155726Z +UID:5Qt99iviVUK9v7HAshjqxQ== +DTSTAMP:20110303T155725Z CREATED:20110303T155756Z -LAST-MODIFIED:20110303T155756Z +LAST-MODIFIED:20110303T155725Z SUMMARY:asdf -DESCRIPTION:When: Thursday\, March 03\, 2011 5:00 PM-6:00 PM. W. Europe - Standard Time\r\nWhere: asdf\r\n\r\n*~*~*~*~*~*~*~*~*~*\r\n\r\nasdf\r\n +DESCRIPTION:asdf X-EVOLUTION-MAPI-CLEAN-GLOBALID:5Qt99iviVUK9v7HAshjqxQ== X-EVOLUTION-MAPI-GLOBALID:5Qt99iviVUK9v7HAshjqxQ== -X-EVOLUTION-MAPI-MID:A8A8850000000001 +X-EVOLUTION-MAPI-MID:68ED860000000001 X-EVOLUTION-MAPI-APPTSEQ:0 LOCATION:asdf DTSTART;TZID=/freeassociation.sourceforge.net/Tzfile/Europe/Berlin: @@ -38,11 +37,15 @@ DTEND;TZID=/freeassociation.sourceforge.net/Tzfile/Europe/Berlin: 20110303T180000 TRANSP:OPAQUE -ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;CUTYPE=INDIVIDUAL; - PARTSTAT=ACCEPTED:MAILTO:Sean.Finney@<domain>.com +ATTENDEE;RSVP=TRUE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT; + CUTYPE=INDIVIDUAL:MAILTO:Sean.Finney@<domain>.com ORGANIZER;CN="Finney, Sean":MAILTO:Sean.Finney@<domain>.com -PRIORITY:1 CLASS:PUBLIC -X-MICROSOFT-CDO-REPLYTIME:20110303T155756Z +BEGIN:VALARM +X-EVOLUTION-ALARM-UID:20110303T155756Z-30137-2060452353-1-6@<hostname> +ACTION:DISPLAY +TRIGGER;VALUE=DURATION;RELATED=START:-PT15M +DESCRIPTION:asdf +END:VALARM END:VEVENT END:VCALENDAR as you can see,the UID and related fields differ. it seems a bit strange actually, that the UID and global id are a base64-encoded representation of a 16-bit value, while elsewhere there's hexadecimal representations of them (and no, it doesn't seem that the base64 value is the same when decoded).
The global ID, as I understood it, was meant to identify "master" meeting uniquely on the server. That's why, after bug #615636, is used that value for UID instead of message ID or evolution-generated UID. Could you provide exact steps how to reproduce this, please? I mean the whole life-cycle of the meeting, like: organizer (machine A) created meeting in X, attendee (machine B) received meeting in Y and replied R, then organizer received.... Please include all details you think is relevant. Thanks in advance.
sure: * organizer created meeting in OWA / outlook, with attendee as required participant * attendee received meeting in evolution and accepts with reply[1] * organizer receives response but at this point the id's have changed and it's not associated with the original event * attendee resultingly now has duplicate events in calendar. [1] the problem also seems to exist if you accept with no reply One thing I've noticed after Bug 643781 is that for some reason when the message comes from outlook it takes a different code path than it does with messages from ema -- the former would go through exchange_mapi_modify_item while the latter would go through exchange_mapi_create_item (which is way testing in evo didn't result in the same crashes). I don't know if that's significant but just thought I'd throw it out there.
If the UID differs, then the event cannot be found in user's calendar, hence a new one is created, instead of the old one modified.
but I promise the event exists, as the diff in the original report was the result of right-clicking and selecting "save as iCalendar" for each of them :) It could be that duplicates are only seen in the calendar in the case that the organizer and attendee are the same person, but if you look at the response sent from the attendee to the organizer you'll also see that it already is not associated with the invitation.
Ok... I have some more information, and a way to both reproduce it and not reproduce it: If I invite myself from OWA, and then in my evo mailbox send/receive to get it, and immediately accept it, then i seem to get a duplicate. If instead, after send/receive I switch to calendar, right click on the MAPI calendar and select refresh (which may make it appear), and then go back to the inbox and accept, there is no duplicate? Does this point in the right direction?
Created attachment 182463 [details] [review] Proposed fix After chatting with milan on #evolution a bit, I think the following should resolve the problem. Basically if an object fetch misses from the backnig store, treat it more like a cache miss and query the server for any changes since the last fetch. then check again before giving up. Tested it myself after nuking my cache, and with a few others here who have larger mailboxes, and it seems to work with no ill effect.
Thanks for a patch, it looks good. Created commit 7de310e in ema master (2.91.92+)