GNOME Bugzilla – Bug 629057
Some events created in evolution are missing in OWA
Last modified: 2011-05-05 11:48:39 UTC
evolution-mapi 0.31.92 If i create single or recurrence event in evolution using mapi, some of them are not shown in owa web interface. But they are shown in Outlook.
Confirming for recurrence events. The single events are shown in OWA for me, though not immediately, as Punit showed me. I spent a bit of time on comparing used properties on each of them, but then I got lost, no results so far.
*** Bug 644809 has been marked as a duplicate of this bug. ***
Still see this in 3.x as well. I spent the better part of the day comparing MAPI attributes to a similar recurrence created in outlook, and the most suspicious difference that I see is the ema-created recurrence object does not have a LID_GLOBAL_OBJ_ID/PidLidGlobalObjectId attribute (or, it is set to 000A, not found). Here's a full run-down of the differences that I saw: The outlook object body is saved as RTF / RTF_COMPRESSED, the ema object as unicode text (probably not significant) All sender address types are all smtp instead of EX (again, probably not significant) The following props only exist in the outlook created version: a 0x81C20002 LID_DAY_INTERVAL a 0x81CD0002 0x0019=25 a 0x81D6000A LID_END_RECUR_DATE, a 0x81D70003 LID_END_RECUR_TIME, a 0x82120003 PidLidTaskMode a 0x82CF0003 PidLidAppointmentColor a 0x82D60003 PidLidAppointmentProposedDuration a 0x82D70003 PidLidAppointmentAuxiliaryFlags a 0x82D90003 PidLidAppointmentProposalNumber a 0x82E20003 PidLidConferencingType, a 0x82E3001F PidLidOrganizerAlias, a 0x82E4001F PidLidDirectory, a 0x82E60003 PidLidAutoStartWhen, a 0x82E7000B PidLidAllowExternalCheck, a 0x82E8001F PidLidCollaborateDoc, a 0x82E9001F PidLidNetShowUrl, a 0x82EA001F PidLidOnlinePassword, a 0x82EB000B PidLidSendMeetingAsIcal, a 0x83CE0040 PidLidValidFlagStringProof, a PidLidCurrentVersion a PidLidCurrentVersionName a PidLidTaskStatus, PidLidPercentComplete, PidLidTaskState, PidLidTaskComplete, PidLidTaskFRecurring, PidLidTaskActualEffort, PidLidTaskEstimatedEffort, PidLidTaskAcceptanceState, PidLidTaskOwnership, PidLidTaskNoCompute, PidLidTaskFFixOffline, PidLidTaskRole, PidLidTaskVersion, PidLidTaskAssigner, PidLidTeamTask, PidLidTaskOrdinal, PidLidAgingDontAgeMe, a PR_ALTERNATE_RECIPIENT_ALLOWED a PR_CONVERSATION_INDEX a PR_DELETE_AFTER_SUBMIT a PR_INTERNET_CPID a PR_MESSAGE_LOCALE_ID a PR_ORIGINATOR_DELIVERY_REPORT_REQUESTED a PR_READ_RECEIPT_REQUESTED a PR_REPLY_REQUESTED The following props do not appear in the outlook created version: d 0x81C2000A LID_DAY_INTERVAL d 0x81CD000A 0x0019=25 d 0x81D6000A LID_END_RECUR_DATE, d 0x81D7000A LID_END_RECUR_TIME, d 0x8315001F PidLidAppointmentMessageClass, d PidLidTaskOrdinal d PR_MSG_EDITOR_FORMAT The following props have different values in each version: m 0x0E2F0003 m 0x0E610003 m 0x81E30003 PidLidIntendedBusyStatus m 0x82DA000B PidLidAppointmentNotAllowPropose m 0x83AC0102 PidLidAppointmentTimeZoneDefinitionStartDisplay, m 0x83AD0102 PidLidAppointmentTimeZoneDefinitionEndDisplay, m PidLidAppointmentStateFlags m PidLidResponseStatus m PR_ICON_INDEX m PR_INTERNET_ARTICLE_NUMBER m PR_OWNER_APPT_ID The following (named) props exist in each version (listed below as ema-version/outlook-version), though in one version are listed as having prop type 000A (== error, not found): p 0x81E1000A/0x81E10102 LID_GLOBAL_OBJID, p 0x81E6000B/0x81E6000A LID_IS_RECURRING p 0x81EB000A/0x81EB0002 LID_MONTH_INTERVAL p 0x81FB000A/0x81FB0002 LID_RECUR_TYPE p 0x81FD001F PidLidRecurrencePattern (prop exists but is empty) p 0x820F000A/0x820F0003 LID_START_RECUR_DATE p 0x8210000A/0x82100003 LID_START_RECUR_TIME p 0x8213000A/0x82130003 LID_TIME_ZONE p 0x8215000A/0x82150102 PidLidTimeZoneStruct p 0x821B000A/0x821B0002 LID_YEAR_INTERVAL
okay, after some incredibly mind-numbing trial and error, I have determined that the problem seems to be the missing LID_TIME_ZONE/PidLidTimeZone/0x82130003 . If I manually add the property in afterwards (using MFCMapi, pretty useful, though the interface stinks), poof! the recurrence appears.
Okay, a lot of investigation has been going on with some help from Milan on IRC. To sum up the problem it's an issue between ema and the openchange libmapi API, in terms of named id's being implicitly resolved. Currently there's no way to disable this behavior with the existing API, so a bug has been filed @ openchange: http://tracker.openchange.org/issues/356 If they provide a new API for our needs we can move to that, otherwise we may be forced to stop resolving named id's locally.
Created attachment 187102 [details] [review] Proposed patch Note that a fix is still required to the above mentioned openchange issue before this patch will be generally useful. From the commit info: For recurring instances, an extra MAPI named property PidLidTimeZone is required for the events to appear in OWA. The value of this property is an index into a rather arbitrarily defined table of timezone DST/SDT transition rules. Since we can not guarantee that the table will match 100% to the current or future timezone transition rules, use a best effort heuristic to find the closest matching rule; for all table entries with the same UTC offset as the current timezone, test dates before and after the transition rules and take the entry which matches closest to what is expected.
Created attachment 187103 [details] [review] quick-hack fix for disabling named id resolution in libmapi/openchange For those who have a local installation of openchange, the following patch disables the problematic behavior. Since ema does all of its own named prop resolution locally, it's not a problem for ema. Of course if you have other apps that might link against libmapi, it may totally mess them up, so this is really only useful if the only reason you installed libmapi was to get evolution-mapi working. In the meantime, Milan is working on an upstream fix in openchange to make the resolution somehow optional, which will be the eventual "real" fix.
oh, and the above ema patch was against the 3.0.x release, in case it wasn't clear. I believe it should also work against older/newer releases, though I haven't tested it.
just to confirm, the proposed patch also works fine in .32, though the "quick hack" fix or the eventual backported fix from openchange will also be needed there.
Thanks for a patch, it looks good (the ema part). I may confess I didn't test it, only compiler, but it's in master sources now: Created commit e2d52eb in ema master (3.0.1+)
(In reply to comment #10) > Created commit e2d52eb in ema master (3.0.1+) err, it's 3.1.1+, I'm sorry.
I am experiencing similar problems. The situation is the following: * Non-recurring Events that I enter into evolution *do* show up on the Exchange Server (and on my phone). * Recurring Events that I enter into evolution *do not* show up on the Exchange Server. Furthermore when I try to edit them in evolution again, everything in the recurrence dialogue is grayed out and nothing can be modified. Funnily, although they are not shown on the Server, they are synchronized to my phone (which might be more liberal concerning the format). Furthermore events that I enter into OWA either do not show up in evolution or they show up after a very long delay (hours, days). Whenever I can get hold of the updated packages, I will do more testing.