GNOME Bugzilla – Bug 704772
Fails to properly import calendar events
Last modified: 2013-08-05 07:42:29 UTC
Using Evolution-ews, I can import a .ics calendar item, but it does not show up on the calendar afterwards. All indications show the import succeeded.
Created attachment 250001 [details] EWS log I can reproduce this. The item doesn't appear even to other clients or OWA, despite the following response to the CreateItem call: <m:ResponseMessages> <m:CreateItemResponseMessage ResponseClass="Success"> <m:ResponseCode>NoError</m:ResponseCode> <m:Items> <t:CalendarItem> <t:ItemId Id="AAMkADQyOWY3OTVmLWEzODYtNDI5NS1hZmE2LThiMjhmYWRjOGQ0NwBGAAAAAAALWV8jNZpCRJWux9Gj6imzBwAxUrM3tYzfT6fnccKZasBfAAAALNTcAACnCUASyhvDT7JwON9NYNl4AAAvyXkpAAA=" ChangeKey="CwAAABYAAACnCUASyhvDT7JwON9NYNl4AAAvynfP"/> </t:CalendarItem> </m:Items> </m:CreateItemResponseMessage> </m:ResponseMessages>
However, if I do an explicit GetItem call for the object ID which was returned, it appears to be there... $ curl -s -S --negotiate -u : -L -H "Content-Type: text/xml" -d @getitem.xml https://irsmsx101.ger.corp.intel.com/EWS/Exchange.asmx | xmlstarlet fo <?xml version="1.0" encoding="utf-8"?> <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"> <s:Header> <h:ServerVersionInfo xmlns:h="http://schemas.microsoft.com/exchange/services/2006/types" xmlns="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" MajorVersion="14" MinorVersion="3" MajorBuildNumber="123" MinorBuildNumber="3" Version="Exchange2010_SP2"/> </s:Header> <s:Body xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <m:GetItemResponse xmlns:m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types"> <m:ResponseMessages> <m:GetItemResponseMessage ResponseClass="Success"> <m:ResponseCode>NoError</m:ResponseCode> <m:Items> <t:MeetingRequest> <t:ItemId Id="AAMkADQyOWY3OTVmLWEzODYtNDI5NS1hZmE2LThiMjhmYWRjOGQ0NwBGAAAAAAALWV8jNZpCRJWux9Gj6imzBwAxUrM3tYzfT6fnccKZasBfAAAALNTcAACnCUASyhvDT7JwON9NYNl4AAAvyXkpAAA=" ChangeKey="CwAAABYAAACnCUASyhvDT7JwON9NYNl4AAAvynfP"/> <t:ParentFolderId Id="AQMkADQyOWY3OTVmLWEzODYtNDI5NS1hZmE2LThiMjhmYWRjOGQ0NwAuAAADC1lfIzWaQkSVrsfRo+opswEAMVKzN7WM30+n53HCmWrAXwAAASzU3AAAAA==" ChangeKey="AQAAAA=="/> <t:ItemClass>IPM.Schedule.Meeting.Request</t:ItemClass> <t:Subject>DEPARTURE 11:05 Local Time (LHR) - United Airlines, Flight 8615 (LHR - YYZ)</t:Subject> <t:Sensitivity>Normal</t:Sensitivity> <t:Body BodyType="Text">United Airlines Flight 8615 London (LHR) to Toronto (YYZ) Depart: 15 Sep at 11:05 (local time) Arrive: 15 Sep at 14:05 (local time) Seats:Seat reservation has not been made. The subject line displays the actual (local) time at point of departure. The calendar entry is based on your time zone configuration. </t:Body> <t:DateTimeReceived>2013-07-24T07:54:11Z</t:DateTimeReceived> <t:Size>2472</t:Size> <t:Importance>High</t:Importance> <t:IsSubmitted>false</t:IsSubmitted> <t:IsDraft>false</t:IsDraft> <t:IsFromMe>false</t:IsFromMe> <t:IsResend>false</t:IsResend> <t:IsUnmodified>false</t:IsUnmodified> <t:DateTimeSent>2013-07-24T07:54:11Z</t:DateTimeSent> <t:DateTimeCreated>2013-07-24T07:54:11Z</t:DateTimeCreated> <t:ResponseObjects> <t:AcceptItem/> <t:TentativelyAcceptItem/> <t:DeclineItem/> <t:ReplyToItem/> <t:ReplyAllToItem/> <t:ForwardItem/> </t:ResponseObjects> <t:ReminderDueBy>2013-09-15T10:05:00Z</t:ReminderDueBy> <t:ReminderIsSet>true</t:ReminderIsSet> <t:ReminderMinutesBeforeStart>1440</t:ReminderMinutesBeforeStart> <t:DisplayCc/> <t:DisplayTo/> <t:HasAttachments>false</t:HasAttachments> <t:Culture>en-US</t:Culture> <t:EffectiveRights> <t:CreateAssociated>false</t:CreateAssociated> <t:CreateContents>false</t:CreateContents> <t:CreateHierarchy>false</t:CreateHierarchy> <t:Delete>true</t:Delete> <t:Modify>true</t:Modify> <t:Read>true</t:Read> </t:EffectiveRights> <t:LastModifiedName>Woodhouse, David</t:LastModifiedName> <t:LastModifiedTime>2013-07-24T07:54:11Z</t:LastModifiedTime> <t:ConversationIndex>Ac6IQvuUC0e6Dn8+SY+aTAsxEZqpgw==</t:ConversationIndex> <t:ConversationTopic>DEPARTURE 11:05 Local Time (LHR) - United Airlines, Flight 8615 (LHR - YYZ)</t:ConversationTopic> <t:InternetMessageId><A7094012CA1BC34FB27038DF4D60D9782FCA77CD@IRSMSX105.ger.corp.intel.com></t:InternetMessageId> <t:IsRead>true</t:IsRead> <t:IsResponseRequested>false</t:IsResponseRequested> <t:IsDelegated>false</t:IsDelegated> <t:IsOutOfDate>false</t:IsOutOfDate> <t:ResponseType>Organizer</t:ResponseType> <t:UID>TripSync-1374561145.99632-air/0/0</t:UID> <t:DateTimeStamp>2013-07-23T13:49:24Z</t:DateTimeStamp> <t:MeetingRequestType>NewMeetingRequest</t:MeetingRequestType> <t:IntendedFreeBusyStatus>Free</t:IntendedFreeBusyStatus> <t:Start>2013-09-15T10:05:00Z</t:Start> <t:End>2013-09-15T18:05:00Z</t:End> <t:IsAllDayEvent>false</t:IsAllDayEvent> <t:LegacyFreeBusyStatus>Tentative</t:LegacyFreeBusyStatus> <t:Location>Flight 8615 (LHR - YYZ)</t:Location> <t:IsMeeting>true</t:IsMeeting> <t:IsCancelled>false</t:IsCancelled> <t:IsRecurring>false</t:IsRecurring> <t:MeetingRequestWasSent>false</t:MeetingRequestWasSent> <t:CalendarItemType>Single</t:CalendarItemType> <t:MyResponseType>Organizer</t:MyResponseType> <t:ConflictingMeetingCount>1</t:ConflictingMeetingCount> <t:AdjacentMeetingCount>0</t:AdjacentMeetingCount> <t:ConflictingMeetings> <t:CalendarItem> <t:ItemId Id="AAMkADQyOWY3OTVmLWEzODYtNDI5NS1hZmE2LThiMjhmYWRjOGQ0NwFRAAgI0H+9p8zAAEYAAAAAC1lfIzWaQkSVrsfRo+opswcAMVKzN7WM30+n53HCmWrAXwAAACzU3AAApwlAEsobw0+ycDjfTWDZeAAAL62eVwAAEA==" ChangeKey="DwAAABYAAACnCUASyhvDT7JwON9NYNl4AAAvxQU8"/> <t:Subject>Baby tea/bath/bedtime</t:Subject> <t:Start>2013-09-15T16:00:00Z</t:Start> <t:End>2013-09-15T19:30:00Z</t:End> <t:LegacyFreeBusyStatus>Busy</t:LegacyFreeBusyStatus> <t:Location/> </t:CalendarItem> </t:ConflictingMeetings> <t:Duration>PT8H</t:Duration> <t:AppointmentSequenceNumber>0</t:AppointmentSequenceNumber> <t:AppointmentState>3</t:AppointmentState> </t:MeetingRequest> </m:Items> </m:GetItemResponseMessage> </m:ResponseMessages> </m:GetItemResponse> </s:Body> </s:Envelope>
Oh, perhaps adding a <SavedItemFolderId> <t:DistinguishedFolderId Id="calendar"/> </SavedItemFolderId> to the CreateItem call would help?
Hm, even that doesn't help. I make the CreateItem call manually with curl, and when I refresh the specified calendar the calendar-factory just gets this: <m:SyncFolderItemsResponse xmlns:m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:t="http://schemas.microsoft.com/exchange/services/2006/types"> <m:ResponseMessages> <m:SyncFolderItemsResponseMessage ResponseClass="Success"> <m:ResponseCode>NoError</m:ResponseCode> <m:SyncState>H4sIAAAAAAAEAO29B2AcSZYlJi9tynt/SvVK1+B0oQiAYBMk2JBAEOzBiM3mkuwdaUcjKasqgcplVmVdZhZAzO2dvPfee++999577733ujudTif33/8/XGZkAWz2zkrayZ4hgKrIHz9+fB8/In6NX+PX+TXoOfjF+w+P9+/d3znePnlwfLC9f3xyb/vJyZOT7Wd7Tw5Onjx49vD+/Z1f8t3X49fXy+nrNmvzk2yZ1de/xqP3f/NZVc7y+mz2azx8/3d/Mq+bolr+Gofv/+p36f/1IqvfypCTX+PX+C3oa0WmzRcNWv4avzl9tUP/H6PNb/j7/P4/fv/PefL0T/8b/sl/+S/9b+78rb/mr/GXHf6n/9Z/8vl/9nv+jftXf+s//88mxa/xa/zK3eTX/zV+jV/r1/hN6P/00O+/76/5a/waXxy/PPvi+AU++TWe3X/2k7/2r9F//jH6/2fe378mvfdlpF33+St/7Pf8Lf6Z3/Ef/fJvWR38h1/8Af/2O+r3FX38a979Z37mv3j5a/yi7z78t8/+9t3P/4zf/f/67u//3f/st/81+ctf49f8H/6HX+9P/SX9r3+tX+N/+HUe/6bpv/br/Nm/zp/0N7z8Nf753+i3+Vt2Tv+d7/xdv+t/9dEf+Sv+na1f79f4Ncf/7T/x627o8w/8b27ss/vyr/dr/Bp3/5lf8t98XVx+g1/z1/iD/h+0fWfMuAIAAA==</m:SyncState> <m:IncludesLastItemInRange>true</m:IncludesLastItemInRange> <m:Changes> <t:Create> <t:MeetingRequest> <t:ItemId Id="AAMkADQyOWY3OTVmLWEzODYtNDI5NS1hZmE2LThiMjhmYWRjOGQ0NwBGAAAAAAALWV8jNZpCRJWux9Gj6imzBwCkO+PY4kfkQK80d7PNywppAAD3MQoHAACnCUASyhvDT7JwON9NYNl4AAAvyn3qAAA=" ChangeKey="CwAAABYAAACnCUASyhvDT7JwON9NYNl4AAAvyn/q"/> <t:ItemClass>IPM.Schedule.Meeting.Request</t:ItemClass> </t:MeetingRequest> </t:Create> </m:Changes> </m:SyncFolderItemsResponseMessage> </m:ResponseMessages> </m:SyncFolderItemsResponse>
Aha. But if I strip the METHOD:REQUEST out of the iCal object before submitting it, *then* it appears on my calendar as it should. (And specifying the folder isn't necessary; it appears on the default calendar)
Hm. This object started off as METHOD:PUBLISH when it was passed to e_cal_backend_ews_receive_objects(). But e_ews_receive_objects_no_exchange_mail() uses e_ews_get_icalcomponent_as_mime_content(), which overrides the METHOD. It's not clear *why* it does that; the commit which added that (4113ebf9) is from the ancient past, before we were even requesting a sane ServerVersion. I'm inclined to simply *stop* doing that, and see if anything breaks... Milan? What do you think?
Fedora package with proposed fix (removing the one obvious line) built at http://koji.fedoraproject.org/koji/taskinfo?taskID=5650812 Let's test that and see who screams. PJ, if it passes basic smoke-testing for you (it did for me when I sent you an invite to a fictitious meeting, as well as testing the specific use case you described above), then we can inflict it upon our internal users too...
The interesting part is, from my point of view, that the importer uses the call to e_cal_client_receive_objects(), which is used for meeting invitations. It might not be a problem, it's only that each backend should do "the right thing" during this call. (In reply to comment #7) > Fedora package with proposed fix (removing the one obvious line) built at I do not think that removing the line: > icalcomponent_add_property (vcal, icalproperty_new_method > (ICAL_METHOD_REQUEST)); from e_ews_get_icalcomponent_as_mime_content() is correct, just the opposite. You should rather pass in the source component's icalproperty_method and use it instead. If this is not set for whatever reason, use the PUBLISH method. For better testing, create a recurring event and move one instance to another time, and change only that single instance. It makes it a detached instance, thus the vCalendar component will make more sense (apart of timezone subcomponents), because you'll have there stored two vEvent components, one as the master object, and the other as a detached instance.
Created attachment 250042 [details] [review] proposed ews patch for evolution-ews; This is what I had on mind. Please give it a try.
http://koji.fedoraproject.org/koji/taskinfo?taskID=5652766
Created attachment 250064 [details] Test .ics file Test .ics file I'm using with the latest EWS from David. Behavior is the same for me, import appears to succeed but the item doesn't show up on the calendar. Packages installed: evolution-3.8.4-1.fc19.x86_64 evolution-data-server-devel-3.8.4-1.fc19.x86_64 evolution-ews-debuginfo-3.8.4-1y.fc19.x86_64 evolution-help-3.8.4-1.fc19.noarch evolution-data-server-3.8.4-1.fc19.x86_64 evolution-ews-3.8.4-1y.fc19.x86_64
Your debug output contains the following: <m:ResponseMessages> <m:CreateItemResponseMessage ResponseClass="Error"> <m:MessageText>MIME content conversion failed.</m:MessageText> <m:ResponseCode>ErrorMimeContentConversionFailed</m:ResponseCode> <m:DescriptiveLinkKey>0</m:DescriptiveLinkKey> <m:Items/> </m:CreateItemResponseMessage> </m:ResponseMessages> This is now a different bug. Firstly an Exchange-side bug which causes it to fail to parse MIME content which it would accept perfectly happily if you were to send the invite to your Exchange email address. And secondly an Evolution bug where there is *no* error reporting from the importer. You should have been *told* about that error.
Many calendar parts report errors on console only. It's bad, but it's in my pile of things to do. I didn't test this yet, thus maybe the importer error reporting is different issue.
(In reply to comment #13) > Many calendar parts report errors on console only. It's bad, but it's in my > pile of things to do. I didn't test this yet, thus maybe the importer error > reporting is different issue. From evolution's console: > Evolution-Importer-WARNING **: receive_objects_ready_cb: Failed to receive > objects: Cannot receive calendar objects: MIME content conversion failed.
Created attachment 250108 [details] [review] proposed ews patch, variant 2 for evolution-ews; Do not use write as mime. I'm able to import the test file into EWS when I do not use the MIME format, like in this patch, but it still might not be correct. Note this patch fixes two more things: a) use folder ID, thus the event reaches the right calendar b) the 'ids' parameter was not defined properly (the caller could not notice the change) The patch does not fix: - import of a recurring event with detached instances As we spoke with David on IRC, his team is trying to figure out with Microsoft people what causes the problem and then it'll be decided what approach will be used (or any new developed).
FWIW you can also often manage to import these events by forwarding them to your Exchange email address. Exchange is lying when it says it can't parse the MIME data. It *can*, as long as it receives it in email. Then you can accept the invitation with a CreateItem request that refers to the *email* rather than containing the MimeContent directly, and it works. And if you then *export* the .ics object from your calendar, as Exchange renders it, delete it from your calendar and attempt to re-import the *Exchange* version of it.... then Exchange says it can't parse the MIME content that *IT GAVE TO YOU*. FPOS.
We filed a ticket (REG:113073010626486) with Microsoft, who responded as follows: > [MS-OXWSMTGS]: Calendaring Web Service Protocol > http://msdn.microsoft.com/en-us/library/ee219567(v=exchg.80).aspx > > It documents complete exchange web service schema and MimeContent element > is not documented as part of it. > > Only the elements documented as part of EWS schema are supported by Microsoft. So although it's clearly present in http://msdn.microsoft.com/en-us/library/exchange/aa564765%28v=exchg.140%29.aspx and it does actually work in some cases, it seems we shouldn't be using it. So we should use the patch in comment 15. And it looks like we should also stop relying on being able to *read* the MimeContent, too I'm in the process of trying to clarify that with them.
Created commit 8c2d923 in ews master (3.9.90+) Created commit a0f04b5 in ews gnome-3-8 (3.8.5+)