Outlook getSelectedItemsAsync
does not populate conversationId
in results
#4974
Labels
Area: Outlook
Issue related to Outlook add-ins
Type: product feature request
Office JS ideas that should be posted to aka.ms/m365dev-suggestions (formerly User Voice.)
In issue #4960 (comment), it was suggested to use
Office.context.mailbox.addHandlerAsync(Office.EventType.SelectedItemsChanged, () => { ... })
andgetSelectedItemsAsync
to overcome the fact thatItemChanged
is fired only for a pinned taskpane.However, the
getSelectedItemsAsync
seems to be bogus by not populating theconversationId
field of the selected items.Your Environment
Expected behavior
With an Outlook extension that defines a taskpane which has multi-select APIs enabled, use the following code:
When the selection changed, you will see the following logs:
Current behavior
The
conversationId
is undefined always when receiving the results back from thegetSelectedItemsAsync
.It should be populated.
Steps to reproduce
conversationId
isundefined
.Provide additional details
It appears this could be a bug with the Outlook native client only (maybe just on OSX too). Indeed, I've performed the same test using
Outlook for Web
and there, theconversationId
field is properly populated.Context
Trying to overcome the limitation that
ItemChanged
which is emitted only for pinned taskpane even though our taskpane even when not pinned is still visible and as such, doesn't react to user changing messages.We worked around the current issue by using
itemId
and retrieving the message in question and finding itsconversationId
. This is incurring extra calls in the backend as theitemId
here is a mutable ID so we need in the backend to first convert to immutable ID (which we store internally for messages) via a Graph API call toTranslateExchangeIds
to make the mutableitemId
immutable and perform the lookup correctly.Useful logs
See logs above, see following screenshots which is my test session.
Thank you for taking the time to report an issue. Our triage team will respond to you in less than 72 hours. Normally, response time is <10 hours Monday through Friday. We do not triage on weekends.
The text was updated successfully, but these errors were encountered: